Headless commerce: when it's worth it and when it's theatre

Every year we have the same conversation a dozen times. A brand outgrows its theme, a developer mentions headless at a conference, a platform rep utters the word "composable", and within a month there's a proposal on a desk that doubles the build budget to achieve — pending further discussion — the same conversion rate. Sometimes headless is exactly right. More often it's architecture as fashion: a sophisticated backend worn as a logo.

We've shipped headless storefronts that transformed businesses and we've talked clients out of headless builds that would have quietly bankrupted their roadmap. This is the decision framework we actually use. If you want the pure technical trade-offs, we wrote those up separately in headless commerce: the honest trade-offs. This article is about the decision — the conditions under which the complexity earns its keep.

The theatre test: four questions first

Before any architecture discussion, we ask four questions. They're deliberately blunt:

What user-visible thing will headless let you do that your current platform can't? Name it. "Faster" is not an answer unless it's quantified; "flexibility" is not an answer at all. A content-rich editorial front with a shoppable layer is an answer. A 3D configurator is an answer. "Our agency recommended it" is theatre.
Who will own the frontend after we leave? Headless moves work from the platform to your team. If the honest answer is "a freelancer, part-time", the architecture will ossify within eighteen months and you'll have paid twice for one store.
Is your catalogue actually complex? Fifteen SKUs of skincare is not complex. Twelve thousand parts with compatibility rules, regional pricing and B2B price lists is. Headless shines when the data model is the hard part.
What's your real traffic and performance ceiling? A well-built theme on a modern platform hits green Core Web Vitals. If your current site is slow, the cause is usually oversized images, tag sprawl and apps — all of which follow you to headless like luggage.

If a project can't answer question one in a sentence, we recommend staying monolithic. Roughly half the brands we assess stay put. The other half fall into recognisable sweet spots.

The sweet spots: when headless genuinely wins

1. Content-led commerce. When the brand IS the content — editorial magazine with a shop attached, recipes with shoppable ingredients, lookbooks with hotspots — the commerce engine is a backend service and the editorial experience is the product. This is where headless is almost unfair. The CMS and storefront share one content model, merchandising happens in the editor's flow, and the shopping layer is a well-behaved guest in the house. We built exactly this pattern for Tallow & Co.'s providore, where the journal and the shop had to be one continuous read, not two sites stapled together.

2. Genuinely interactive product experiences. Configurators with real-time visualisation, fit finders backed by rules engines, subscription builders with live dosage maths — the kind of interaction where the buy-button is the end of a rich client-side experience. When half the application is state that never touches the server, you want a real frontend framework, and once you have one, rendering the catalogue with it costs little. The Osprey Outdoor pack configurator is the canonical case — the configurator is the storefront.

3. Multi-brand, multi-region, one backend. A group running six brands across three currencies from one catalogue and one fulfilment stack. Headless here isn't a luxury — the monolith's one-theme-per-store assumption becomes the constraint. One commerce API, six frontends, shared component library. The economics invert: headless is cheaper than six independent tuned monoliths.

4. App-adjacent commerce. When the same catalogue must serve a web store, a native app, in-store kiosks and wholesale ordering, the API already exists for business reasons. The web store is just another client.

Notice what's absent from this list: "we want it fast", "we want it modern", "we're growing". All fine desires, none architectural.

Total cost of ownership: the spreadsheet nobody shows you

The build cost delta is the visible tip: headless typically runs 1.5–2.5× the initial build of a tuned theme build. The submerged costs are the ones to model honestly over three years:

Hosting and plumbing. A headless frontend needs a host, a CDN strategy, preview environments, and someone who understands caching headers. Figure $300–1,500/month where the monolith charged near nothing. The caching layers cake explains what you're now responsible for.
The app ecosystem evaporates. This is the cost that shocks people. Reviews, loyalty, bundles, size charts, shoppable Instagram — on a monolith these are $20/month installs. Headless, each one is an integration project or a licensed API service. Audit your app list before signing: every installed app is either an API you now wire up yourself or a feature you quietly ship without.
Two systems to keep current. Platform updates still happen; now your frontend has its own dependency treadmill too. Budget a maintenance retainer, not just a build.
Preview and editing friction. Marketers lose the theme customiser. Previewing unpublished content in a headless stack requires deliberate plumbing. If your team merchandises daily, this workflow is either built properly — draft previews, visual editing — or your content team will email engineers CSVs, and everyone loses.
Checkout stays platform anyway. On most platforms, checkout remains hosted regardless of headless. You get framework ownership of everything except the most conversion-critical pages — worth knowing before you cite "control" as the reason.

A fair three-year TCO model — build + hosting + apps-replaced + maintenance + the cost of slower content iteration — is the single document that most reliably settles this argument. We've watched it reverse decisions in both directions.

The team requirement, stated plainly

Headless is a capability commitment, not a purchase. The minimum viable team around a headless store is: one frontend developer who owns the storefront (yours, an agency on retainer, or an in-house hire), one person who can reason about the commerce API and webhooks, and a content workflow that doesn't bottleneck on either. If that sounds like your organisation, proceed. If it sounds aspirational, the monolith plus a well-invested theme is not a compromise — it's the correct architecture for your team, and the marketing site's perceived speed will come from image discipline and restraint, not from a rendering strategy.

The middle path everyone forgets

Between "full theme" and "full headless" live the hybrids, and they're frequently the right answer for mid-market brands: a monolithic storefront for catalogue and checkout, with headless islands where interaction justifies them — a configurator here, a subscription builder there, editorial sections served from a real CMS. Islands thinking applies to commerce exactly as it does to content sites: sprinkle, don't soak. You buy interactivity by the square metre instead of rebuilding the building.

Our actual recommendation heuristics

When we scope commerce builds, the shorthand runs:

Under ~$2M online revenue, conventional catalogue, small team: tuned theme, obsessive performance budget, invest the difference in merchandising and PDP design. Headless here is theatre with a maintenance bill.
Content-led brand, or interaction-heavy product, or multi-brand group: headless, scoped to the sweet spot, with the app-ecosystem audit done before contract.
In between and unsure: hybrid. Ship the island that matters. Revisit in two years with real data instead of conference Talk Energy.

And one closing rule that has never been wrong: the platform decision should be the least interesting thing about your store. If the architecture is the most exciting part of the proposal, the proposal is confused about what sells product.

Key takeaways

Headless earns its complexity in four conditions: content-led commerce, deeply interactive product experiences, multi-brand/multi-region, and app-adjacent catalogues. "Fast" and "modern" are not conditions.
Model three-year TCO: build multiplier, hosting, the app ecosystem you'll re-build or lose, maintenance, and content-iteration drag.
The app audit is the silent deal-breaker — every installed app is a future integration project.
Headless is a team commitment. No permanent frontend owner, no headless.
The hybrid middle path — monolith plus interactive islands — is underrated and often correct.
Architecture should be the least interesting thing about your store.

FAQ

Is headless faster? It enables faster; it doesn't confer it. A headless build with unoptimised images, a tag manager landfill and no caching discipline is slower than a disciplined theme. Performance comes from budgets and craft, not topology.

Will headless hurt our SEO? Not inherently — server-rendered headless storefronts are excellent for SEO. What hurts SEO is a client-side-rendered SPA shipped by accident, unrendered pagination, and broken canonicals during migration. Both are process failures, not architecture failures. Our site migration playbook covers the guardrails.

Can we go headless later? Yes, and it's a sane path — the domain knowledge, content model and product data all transfer. What doesn't transfer is the theme build itself, which is another argument for keeping the theme investment modest if headless is on the horizon.

What about Shopify Hydrogen / platform-native headless? Platform-native frameworks narrow the gap meaningfully — hosting, preview and checkout integration come closer to free. They also re-tie you to the platform you were decoupling from. That's often a fair trade; just make it with eyes open.