Most themes do not fail on launch day. They fail six months later, when the fourth agency has bolted on the third one-off section, the CSS is 400 kilobytes of overrides, and nobody can change the homepage without breaking a product page. The store still works—it is just terrifying to touch.
Architecture is what prevents that. Online Store 2.0 gives us genuinely composable building blocks—sections, blocks, section groups and JSON templates—but the platform will happily let you build a mess with them. Scaling is a discipline you impose, not a feature you enable.
01 · Units
Sections are the unit of the store.
In OS 2.0 the section is the atom of composition. A well-built theme is a library of focused sections that merchandisers can add, reorder and configure on any template. The failure mode is the "god section"—one enormous file with thirty settings that tries to be a hero, a product grid and a testimonial wall depending on a dropdown.
Keep sections small and single-purpose. A section should have one clear job and expose only the settings that job needs. Blocks handle repeatable sub-items inside it. When a section starts sprouting unrelated options, that is the signal to split it.
One section, one responsibility. If you cannot name it in three words, it is doing too much.
02 · Reuse
Snippets, not copy-paste.
The same product card appears on the homepage, collection pages, search results and cart recommendations. If that markup is pasted into four sections, one design change becomes four edits and eventually four subtly different cards. Extract it once into a snippet and render it with parameters everywhere.
- Render shared UI—cards, price displays, badges, media—through snippets with clear inputs.
- Pass data explicitly with the render tag so snippets have no hidden dependencies.
- Keep snippets presentational; let sections own the data and the settings.
This is ordinary software hygiene applied to Liquid. It is also the single biggest lever on long-term maintainability: the store where the product card lives in one place is the store you can redesign in an afternoon.
03 · Settings
Settings over hard-coding.
Every value a non-developer might reasonably want to change belongs in a setting, not baked into the template. Headings, toggles, layout choices, the number of columns, whether a badge shows—all of it. The test is simple: if changing it would otherwise require a developer and a deploy, it should be a setting.
But restraint matters here too. A section with fifty settings is as unmaintainable as one with none, because nobody understands the combinations. Expose the choices the brand will actually make, give them sensible defaults, and ship presets so editors start from a good state instead of a blank one.
04 · Assets
One CSS and JS strategy.
Uncontrolled styling is how themes rot. Pick one approach and hold the line: scope styles to their section, use design tokens for colors, spacing and type, and resist the temptation to patch every issue with another global override. The stylesheet that only ever grows is a stylesheet nobody can reason about.
- Load JavaScript only where it is used; a homepage carousel should not ship on the cart.
- Prefer small, dependency-free web components over heavy shared libraries.
- Keep third-party scripts off the critical path so the theme's own speed is not hostage to an app.
Architecture and performance are the same conversation. A theme organized into focused sections that load only what they need is fast almost by accident, because nothing loads that a given page does not use.
05 · Guardrails
Linting and version control.
A theme that scales is a theme under version control. Develop with the Shopify CLI, keep the source in Git, and review changes like real code. This alone prevents the classic disaster where someone edits the live theme in the browser and overwrites two days of work.
Run a linter—Theme Check—in the pipeline so undefined objects, deprecated filters and accessibility gaps are caught before they ship. Guardrails are not bureaucracy; they are how a team of several people keeps a shared codebase coherent.
06 · Handover
Design for the next editor.
The person who maintains this theme in a year may not be you, and they will not read your mind. Name sections and settings in plain language, group them logically in the editor, and leave short comments where a decision is non-obvious. Good architecture is legible to the people who inherit it.
You are not just building for the launch. You are building for every edit after it.
Quick check
Will this theme age well?
- Every section has a single, nameable responsibility.
- Shared UI lives in snippets, rendered with explicit inputs.
- Editable values are settings with defaults and presets.
- Styles are scoped and tokenized; scripts load only where used.
- The theme is in Git, linted, and reviewed like code.
Structure is a feature.
Customers never see the architecture, but they feel it—in the speed, in how quickly the brand can ship a new campaign, in the fact that the store still looks intentional after two years of edits. We treat theme structure as part of the deliverable, not an afterthought, because it is the part that decides whether the store keeps getting better or slowly falls apart.