Building a Shopify Section Library Instead of Using a Theme

I deleted my pre-made theme and rebuilt the storefront from 87 custom sections. The store loads faster, every page is editable by a non-coder, and I no longer fight someone else's CSS. Here is what that decision actually bought me, where it cost me, and the structure that keeps it sane for one person.

Why I Stopped Using a Pre-Made Theme

A pre-made theme is a contract you did not read. You inherit thousands of lines of Liquid, three layers of CSS specificity, and JavaScript that runs on every page whether you use it or not. The first time I tried to change a product grid from 4 columns to 3, I spent 40 minutes tracing a class name through four files. That was the moment I started counting.

The theme I bought had 31 sections. I used 9 of them. The other 22 still shipped their schema, their settings, and their assets to every store render. When I ran a Lighthouse audit, 60 percent of the unused CSS was theme defaults I had never touched. That dead weight is invisible until you measure it.

Custom sections flip the relationship. Instead of starting with everything and deleting, I start with nothing and add. My current library has 87 sections, but a typical page pulls in 6 to 9 of them. Nothing renders that I did not write. When a page is slow, I know exactly which section to blame because I wrote all of them.

The other reason is editing. On Shopify, the section is the unit a non-technical editor touches in the theme customizer. If your sections are well-scoped, a person who cannot read Liquid can build a full landing page by dragging blocks. With a bloated theme, half the settings are labeled in ways only the theme author understands. My sections have plain labels because I wrote them for myself six months from now.

The tradeoff is real and I will not pretend otherwise. A pre-made theme gives you a working store in an afternoon. My setup took far longer to reach the same visual baseline. The question is not which is faster on day one. It is which one you can still change on day 200 without dreading it. For me the answer was clear after the third theme update broke my custom edits and I had to redo them by hand.

The 87 Sections, Grouped by Job

Eighty-seven sounds like a lot until you see how they cluster. I have roughly 12 layout primitives (hero, two-column, three-column, spacer, divider, container). I have 18 content blocks (rich text, image with text, FAQ accordion, quote, stat row, logo strip). I have 14 commerce sections (product grid, featured product, collection list, cart drawer contents, upsell row). The rest are page-specific one-offs that I keep isolated so they never pollute the reusable set.

The grouping is not decoration. It is how I decide whether to build new or reuse. When I need a new page, I check the primitives first. About 70 percent of any new page is assembled from sections that already exist. The remaining 30 percent is either a variant of something I have or a genuinely new pattern that earns its place in the library.

I keep a flat count because it tells me when the library is rotting. When I crossed 70 sections, I noticed three near-duplicate hero variants that differed only by padding. I merged them into one section with a padding setting. That is the maintenance loop: count, spot duplicates, consolidate. A theme hides this because its sections are someone else's problem. My count is my own dashboard.

The single biggest win from grouping is naming. Every section gets an `rx-` prefix and a job-based name: `rx-hero-split`, `rx-content-faq`, `rx-commerce-upsell-row`. When I open the section picker in the customizer, related sections sort together alphabetically. I can find the FAQ section in two seconds because every content section starts with `rx-content-`. Without a naming convention, 87 sections is chaos. With one, it is a filing cabinet.

I also tag sections by stability. A section marked stable in my notes has not changed in three months and is used on five or more pages. I do not touch those without a reason. An experimental section lives in a separate mental bucket and I expect to delete or rewrite it. This separation stops me from breaking working pages while tinkering with new ideas. If you want the deeper context on how I organize Liquid itself, see Shopify Liquid Sections: A Developer's Quick Reference.

Where Custom Sections Actually Cost You

I will be honest about the bill. Custom sections cost you roughly 3x the upfront time of configuring a theme, and the cost shows up in four specific places.

First, schema. Every section needs a JSON schema block defining its settings, blocks, and presets. A hero with 8 settings is 60 lines of schema before you write a single line of markup. Get a comma wrong and the section silently vanishes from the customizer with no error message. I lost an afternoon to a trailing comma once. Now I validate schema in a linter before I save.

Second, responsive behavior. A theme handles mobile breakpoints for you, badly but automatically. When you write sections yourself, every section is your responsibility at every screen width. I test each new section at 375px, 768px, and 1440px before I call it done. Skip this and you ship a desktop-only section that looks broken on the device most of your traffic uses.

Third, accessibility. Themes ship with focus states, ARIA labels, and keyboard navigation baked in. When you start from nothing, you start from nothing on accessibility too. I keep a checklist: alt text fields in schema, focus-visible styles, semantic headings. It is easy to forget when you are racing to ship a landing page.

Fourth, the no-team tax. There is no theme author to file a bug with. When something breaks, the entire surface area is mine. This sounds scary and is actually the point. The cost of total ownership is total responsibility, and the benefit is that nothing is ever a black box. I traced a layout shift to a single missing height attribute in 10 minutes last week because I knew every line involved.

The honest summary: if you ship one store and never touch it, a theme wins on cost. If you run a store you change weekly, the section library pays back the upfront cost within the first two months of edits. I crossed that break-even around week 7. The whole approach pairs with how I run the rest of the studio, which I documented in the Claude Blueprint.

The Structure That Keeps It Maintainable Solo

One person cannot afford messy code, because there is no one else to clean it up. My maintainability rules are boring on purpose.

Rule one: one section, one job. A section that does two things becomes two settings panels that confuse future me. When a section grows a second job, I split it. The `rx-hero-split` section only renders a split hero. It does not also handle a video background. That is a different section.

Rule two: settings over hardcoding. Anything I might want to change later becomes a schema setting. Padding, colors, alignment, max-width. The first version of my content sections had hardcoded 80px padding. The fifth version has a padding setting with small, medium, and large presets. This is what lets me edit pages in the customizer instead of the code editor, which matters when I am moving fast.

Rule three: shared snippets for repeated logic. Buttons, image rendering with proper srcset, and price formatting all live in snippets that sections include. When I improved my image loading to use the native lazy attribute and correct sizing, I changed one snippet and 31 sections inherited the fix. That single change cut my largest contentful paint by about 400ms across the store. Without shared snippets I would have edited 31 files.

Rule four: a section template I copy. Every new section starts from a skeleton file with the schema scaffold, the wrapper div with the `rx-` class, and a comment block for notes. I never write a section from a blank file. The template enforces my naming and structure before I think about the actual content. This removes 15 minutes of boilerplate per section and, more importantly, removes the chance to forget the wrapper class that my CSS depends on.

For scheduling the content that promotes these pages, I let Buffer handle the social queue so I stay in the code instead of the calendar. I covered the broader publishing workflow in more depth, but the section library is the foundation everything else sits on. The pages have to be editable and fast before promotion means anything.

The result of these four rules is that I can build a new landing page in under an hour using existing sections, and I can change a global style by editing one snippet. That is the entire promise of the approach: speed of change, not speed of launch.

Bottom Line

A pre-made theme is the right call if you launch once and walk away. The section library is the right call if your store is a living thing you edit constantly. I run 87 sections because I change pages every week and I refuse to fight someone else's code to do it.

The honest math: custom sections cost roughly 3x the setup time, and they pay it back in the first two months if you edit often. The naming convention matters more than the Liquid skill. The shared snippets matter more than any single section. Discipline beats cleverness here, because the enemy is not difficulty, it is drift.

If you are deciding between the two, ask one question: how often will you change this store? If the answer is rarely, buy a theme. If the answer is constantly, start building primitives. For the wider system I run around this, the Claude Blueprint walks through how the pieces connect. Start with 12 sections, not 87. The library grows itself once the foundation is right.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)