There is a story teams tell themselves on ambitious builds: distinctive design means custom code, and custom code means a theme that only its author understands, that slows down over time, and that breaks the moment someone touches it. So brands either settle for a templated look to stay safe, or go bespoke and quietly accept the mess.
Both halves of that story are avoidable. A store can be genuinely custom and still be fast, editable, and maintainable years later — if the customisation is built as a system rather than a pile of one-off pages. The section is the unit of that system, and discipline is what keeps it from becoming chaos.
01 · The tension
The false choice.
The fear is legitimate but the framing is wrong. Chaos does not come from custom design; it comes from custom design built without a plan. A page hand-coded in isolation, with its own styles, its own markup, and its own quirks, is a liability the moment the person who wrote it moves on.
The alternative is not less ambition. It is the same ambition, expressed through reusable parts that share a spine. You get the distinctive result and a theme that a new developer — or the merchant themselves — can understand and extend without archaeology.
Chaos is not a side effect of custom work. It is a side effect of custom work without a system.
02 · The system
The section system as the answer.
Online Store 2.0 gives every page a section-and-block architecture, and used well it is the antidote to bespoke sprawl. Instead of unique pages, you build a library of purposeful, configurable sections that compose into any layout.
- Each section does one job well — a hero, a proof band, a comparison, a story block — and does it consistently everywhere it appears.
- Blocks handle the variation, so one section covers many use cases through settings rather than through forked copies.
- Every page is assembled, not authored, from parts that already exist, tested and performant.
- New requirements extend the library, adding a section others can reuse, instead of a dead-end one-off.
The custom look lives in the design of the sections. The maintainability lives in the fact that there is a finite, well-understood set of them.
03 · Tokens
Constraints that set you free.
A section system needs a shared vocabulary underneath it or every section drifts into its own dialect. Design tokens — a defined palette of colours, type scales, spacing steps, and radii, expressed as CSS custom properties — are that vocabulary.
When every section draws from the same tokens, the store stays coherent no matter who assembles the page, and a brand-wide change is one edit rather than a hunt through fifty files. Constraints feel limiting for about a day; after that they are what let a small team move fast without the work fracturing into inconsistency. Freedom on a build comes from good rails, not from their absence.
04 · Performance
Speed baked into the system.
The quiet advantage of a section system is that performance discipline gets built in once and inherited everywhere. Set the rules at the section level — reserved image dimensions, lazy-loaded media below the fold, scripts scoped to the sections that need them — and every page composed from that library is fast by default.
Contrast that with the pile-of-one-offs approach, where each page reintroduces its own layout shifts and its own scripts, and speed erodes page by page. A store built on well-behaved sections holds its performance budget as it grows; a store built on bespoke exceptions leaks it. Custom does not have to mean slow — but only if speed is a property of the system, not an afterthought on each page.
05 · Governance
Editable without breakable.
The final payoff of a good section system is that it hands control back to the merchant safely. Because sections expose their options as theme settings, a marketer can build a campaign page, reorder a homepage, or swap a hero without touching code — and without the power to break the layout.
That is the balance a custom build should aim for: expressive where it counts, constrained where it matters. This is core to how we approach development — a theme that is a toolkit the client's team can wield, not a locked box they have to call us to open. And when we inherit a store that skipped this discipline, the cleanup usually starts by finding the accumulated one-off code and dead app fragments a scan turns up, then rebuilding the mess back into a proper library. Order is cheaper to keep than to restore.
Quick check
Is your custom build a system?
- Pages are assembled from reusable sections, not hand-coded one-offs.
- Sections draw styling from shared design tokens.
- Performance rules live at the section level and are inherited everywhere.
- Merchants can compose pages safely without editing code.
- New needs extend the library rather than forking new exceptions.
Distinctive and durable.
The best custom stores do not look templated and do not behave like a house of cards. They achieve that by treating customisation as engineering — a library of considered parts, a shared vocabulary, and speed built into the foundation. Get the system right and you can be as bold as the brand demands without ever inheriting the chaos that usually comes with it.