How our templates are built and why that matters to your site

Most people never think about how their website template is put together, and mostly they shouldn't have to. But the architecture underneath a template decides things you feel every day: whether you can move a section without help, whether an update can break your home page, and whether the shop looks like the rest of the site or like something bolted on.

We built themes for other platforms for years before building our own, so we watched this evolve from the inside. Here's the short history, how our templates work now, and — the part that actually matters — what it means for the site you have to live with.

Era one: the template file

For most of the web's commercial history, a theme was a set of files. The home page was a file. The product page was a file. Where things sat on the page was decided in that file, in code, by whoever wrote it.

If you wanted your testimonials above your product grid instead of below it, that wasn't a setting — it was an edit. You emailed your developer, or you opened the file yourself and hoped. A handful of options existed in a settings panel, but they were the options the theme's author had thought to expose, and moving anything meaningful meant touching code.

Worse, your edits and the theme's code lived in the same place. When the theme's author shipped an update — a bug fix, a security patch, a new feature — installing it meant overwriting the files you'd customized. Merchants learned to be afraid of updates, and a lot of stores simply stopped taking them. We supported plenty of sites running two-year-old theme versions because nobody dared touch it.

Era two: sections

The breakthrough was separating what a page is made of from what order it's in. Instead of one file describing the whole home page, a theme shipped a library of independent sections — a hero, a product row, a testimonial block — and the page became a list of which sections to show and in what order.

That list lived in data, not code. Suddenly a merchant could drag a section up, hide one, duplicate another, and edit its settings without going near a file. It was a genuine shift, and it moved real control from developers to the people whose business it was.

It also left something unresolved. Sections were still authored per theme. Every theme had its own hero, its own product grid, its own gallery — similar in spirit, different in every detail. So switching themes still meant starting over, and any feature that lived outside the theme (reviews, bookings, a subscription widget) still arrived as a stranger with its own fonts and its own opinions.

Sections solved layout. They didn't solve the seams — the visible joins between the theme and everything a real business bolts onto it.

How our templates work

We started from the seams. Four decisions define our templates, and each one is there because of something we watched go wrong on a merchant's site.

One render path

The editor and the published page run the same component. Not a preview that approximates the result — the actual thing, with your actual content, rendered by the actual code that will serve your visitors.

This sounds like an implementation detail and it isn't. It's why there's no gap between what you arrange and what ships, and why you never discover after publishing that something looked different in the editor. There's only one thing to look at.

Blocks declare what you can edit

Every section in every template declares its own editable fields — this headline, that image, these three colour swatches, this link to another page — alongside its defaults and how it renders. Change what a section offers and the editor panel and the live page both update from that one change.

The practical effect is that the controls you see are never stale, never lying, and never a superset of what actually does anything. If a field is in the panel, it changes the page.

Shared features, skinned per template

The cart, the product page, site search, the journal, locations, subscriptions and reviews are not re-authored in every template. They're one implementation each, styled through design tokens that every template sets for itself — its fonts, its colours, its spacing.

So the slide-out cart on a coffee roaster's site and the one on a pet shop's site are the same cart, and they look nothing alike. You get a feature that's been hardened across the whole catalog, wearing your design. That's the seam problem solved at the root: there's no third party to style, because there's no third party.

Live data arrives at the section, never fetched by it

Sections don't go looking for your products, posts, reviews or locations — the page hands them in. That keeps every section fast and predictable, and it's why a “featured products” block on your home page shows real inventory and real prices rather than a cached copy that drifts.

Why every template has to pass the same audit

A catalog of templates has a quiet failure mode: features that exist in most of them and are silently missing from a few. The template renders, nothing errors, and the gap only surfaces months later when a merchant goes looking for something and finds it isn't there.

So we don't rely on remembering. Every template has to pass the same automated parity audit before it ships — two dozen mechanical checks that read the template's real structure and wiring rather than guessing from names. A few of them, to give you the flavour:

• Search is present in both the desktop and the mobile navigation, not just one.
• The logo height is adjustable, so your wordmark doesn't shove the menu off a phone screen.
• A privacy page and a terms page exist and the footer links to them.
• Your uploaded logo overrides the template's placeholder everywhere it appears.
• The cart trigger is present but gated per site, so a brochure site never sprouts a cart it didn't ask for.
• Testimonial sections render only real, published reviews — the template's sample quotes are visible while you're editing and can never reach a live page.
• Every section is grouped by type in the editor, so the menu you browse is organised rather than a flat list of forty names.

That last category is the one we care about most. An invented testimonial from an invented customer appearing on a real business's live page is not a cosmetic bug, and “we'll remember not to do that” is not a control. The rest of the audit — the parts a script can't settle, like whether the mobile menu animates in the right direction — is checked in a browser, by a person, on every template.

What this means for your site

Updates can't overwrite your work

Your pages are content — a document describing which sections you chose, in what order, with what words. The template is code we maintain. When we improve a section, fix a bug or ship a new capability, it arrives underneath your content without touching it. There is no version of your theme to update, no merge to be afraid of, and no reason to sit on an old release.

Changing your mind is cheap

Because content is separate from design, moving to a different template doesn't mean re-entering your site. And you don't have to gamble on it: make a sandbox version of your site, switch the copy to the new template, look at it privately for as long as you like, and apply it only if it's better. Your live site keeps running the whole time, with its domain, orders and customers untouched.

Consistency is structural, not disciplinary

Your brand colours are set once and read by every section, including the shared ones — and by your newsletters. You can't accidentally end up with three shades of your accent colour across five pages, because there's one place the colour comes from.

Your shop is not a guest

Products, cart, checkout, reviews and subscriptions are built from the same materials as your About page. There's no visual border where the website ends and the store begins, because architecturally there isn't one.

---

The point of all this plumbing

None of this should be visible to you. The measure of the architecture is that you never think about it: you drag a section and it goes where you put it, you publish and it looks like the preview, you change your colours and everything follows, and a year from now your site has quietly gained features you didn't have to install.

The history of website templates is really the history of moving control from the person who wrote the code to the person who owns the business. Sections moved layout. Shared components and a single render path move the rest — the parts that used to be a support ticket.

Which is, in the end, the whole job: make the powerful thing boring, so you can get on with your actual work.