Headless commerce: the honest trade-offs

Somewhere around 2021, headless commerce stopped being an architecture and became a personality type. Conference talks promised infinite flexibility; agencies quoted decoupled builds the way mechanics quote turbos — everyone wanted one, few knew why, and the invoice was always a surprise. Now the market has sobered up, and the honest answer is the one nobody put on a slide: headless is brilliant for a narrow set of teams and a burdensome hobby for everyone else.

We build both. Fernleigh Wines runs a headless storefront because content is their product; Fern & Forage runs a ruthlessly tuned hosted theme because nobody there will ever write a line of code, and their florist shouldn't have to. Both were the right call. Here's how to make yours.

What headless actually buys you

Strip the vendor marketing and headless commerce — a custom frontend decoupled from the commerce engine via APIs — buys four things:

A real performance ceiling. Full control of the render path, the bundle, the image pipeline. A good headless storefront on a modern framework can hit LCP under a second on mid-tier phones; a theme-based build will plateau somewhere around "fine". Whether your customers can feel the difference depends on where you start.
Editorial freedom. Content-rich commerce — lookbooks, recipes, provenance stories, buying guides woven into the catalogue — is where headless sings. If your marketing site and store fight each other for the same URL space, decoupling ends the war.
One frontend, many engines. Multi-brand, multi-region, marketplaces, or a business that sells subscriptions and one-off and wholesale from the same inventory. Orchestration is headless's real superpower.
Team autonomy. The storefront team ships daily without waiting on platform release trains. For product-led organisations, this velocity is the whole point.

Notice what's absent: cheaper, simpler, easier. Headless is none of those.

What it actually costs

The TCO line items that surprise teams, roughly ordered by the volume of the post-launch phone call:

You now own a frontend. Obviously — but teams underestimate what hosting, previews, deployments, incident response and dependency upkeep mean as a permanent capability. Someone on your side must be on call for the storefront, forever.
Everything you'd never seen is now yours to build. Cart persistence, checkout handoff, promo validation, inventory states, tax display, localised pricing, back-in-stock flows. Themes ship these battle-tested; you inherit them as tickets. Budget three to five engineers for year one of a serious catalogue.
Preview and editorial tooling. Decouple naively and your merchandisers lose visual preview — the thing they use all day. Rebuilding a preview environment merchandisers love takes real product work, and it's never in the quote.
Integration glue has a maintenance half-life. Every app you'd have clicked "install" on in a hosted platform — reviews, loyalty, subscriptions, search — becomes an API integration you babysit.
SEO risk during migration. You'll rebuild every URL, template and structured-data pattern that currently ranks. Our technical SEO checklist exists largely because of headless migrations that forgot canonicals.

When the tuned theme wins — honestly

We say this as a studio that charges more for headless: choose the theme when —

Your catalogue is under a few hundred SKUs with conventional merchandising.
Your differentiation is product, brand and retention — not site experience. (Checkout friction lives mostly in the platform's checkout either way; our PDP design piece applies fully on themes.)
Nobody technical will touch the site between agency engagements.
The budget delta is better spent on photography, email and ads. It usually is.

A well-tuned premium theme, properly configured with a disciplined app stack, converts. We've audited dozens. The stores failing on themes are failing on content, imagery and offers — none of which headless fixes.

When headless earns it

Score your situation. We use this scorecard in discovery; five or more "yes" answers is where headless starts paying rent:

Content and commerce genuinely merge — editorial drives a material share of revenue.
You have (or will hire) at least two frontend engineers on staff or retainer.
You're multi-brand, multi-region, or multi-model (B2C + B2B + marketplace).
Your roadmap needs experiences the theme can't express — configurators, bundles with custom logic, subscription builders. The Osprey Outdoor configurator is the poster case: that interaction simply doesn't exist in theme-land.
Sub-second loads plausibly move your revenue — you have the traffic for performance to compound and the analytics to prove it.
Your team ships continuously and platform release cycles are a genuine bottleneck (not a rhetorical one).
You have a clear 3-year ownership plan for the frontend — someone wakes up owning it.

Hybrid deserves a mention: hosted checkout and catalogue, headless content layer only, or headless for the flagship market and themes elsewhere. Purity is not a requirement; competence is.

If you go headless, go like this

Sketch-to-checkout first. The riskiest flows are cart, checkout handoff and inventory truth. Build them in week one, not sprint six.
Editorial preview is a launch blocker. Merchandisers signing off without preview is how you lose the internal vote that matters.
Adopt the boring stack. Framework-agnostic advice: pick the thing your team already knows, hosted somewhere with edge rendering and preview deployments. Novel tech on top of novel architecture is a parlay.
Budget the app replacement list. Write down every hosted-platform app you use today, find its headless path, cost it. This document ends arguments.
Set performance budgets before design. Core Web Vitals discipline is the whole point of the exercise — codify LCP/INP/CLS targets in the brief or you've bought speed you'll never enforce.

The Hearthbrew subscription storefront shows the ceiling: headless, editorial-first, subscription logic woven into the PDP, performance budgeted from day one. It works because Hearthbrew had the team, the content engine and the traffic. Remove any leg of that stool and we'd have told them to keep the theme.

Key takeaways

Headless buys performance ceiling, editorial freedom, orchestration and team autonomy — never cheapness or simplicity.
The hidden costs are frontend ownership, rebuilding "free" commerce primitives, preview tooling and integration maintenance.
Under ~300 SKUs with conventional merchandising and no in-house engineering, a tuned theme wins almost every time.
Use a scorecard; five-plus structural "yes" answers is the headless threshold. Consider hybrids.
If you go, build checkout first, treat editorial preview as a blocker, and set performance budgets in the brief.

FAQ

Is headless better for SEO?

Not by default — it's capable of better Core Web Vitals and safer URL control, both of which help. But migrations are where rankings go to die, and a fast theme beats a botched decouple. SEO outcomes follow execution, not architecture.

Can we go headless with a small team?

One excellent engineer plus a strong agency retainer is the realistic floor, and only for a lean catalogue. Below that, every incident is an emergency and every feature is a queue. The theme exists for you — that's not a slight.

What about "composable" suites that promise headless without the pain?

They reduce integration glue, not ownership. You still own the frontend, the preview tooling and the uptime. Evaluate them on team topology, not on the demo environment.

When is replatforming from headless back to a theme right?

More often than LinkedIn suggests — typically when the founding engineer leaves and the storefront becomes a haunted house. There's no shame in consolidating; the shame is paying headless TCO for theme-level ambition.