When headless commerce is worth it — and when it isn't

Headless is the most requested architecture we talk clients out of. Not because it is bad — it is genuinely excellent for certain situations — but because the reason people ask for it is usually solvable more cheaply.

What headless actually is

Your storefront becomes a separate application. It fetches products, collections and cart state from the commerce platform through an API, and you build and host the frontend yourself. The platform continues handling catalogue, payments, orders and fulfilment behind it.

You gain complete control over the frontend. You take on responsibility for building and running it.

What you give up

This half gets discussed less than it should.

The theme editor. Your marketing team can no longer drag a section, change a banner or reorder a page. Every visual change becomes a development ticket with a deployment behind it.

For teams accustomed to making their own changes, this is a bigger day-to-day shift than the build cost. It is also the thing most often glossed over during the decision.

Most of the app ecosystem’s frontend. Apps that add storefront functionality generally do it by injecting into a theme. Without a theme, they have nowhere to inject. Some offer headless-compatible components; many do not. Every app you rely on for frontend behaviour needs checking before committing.

Simplicity. You now have two systems, two deployment pipelines, and a hosting bill for the storefront.

What you gain

A higher performance ceiling. You control every byte. Nothing loads that you did not choose. Done well, headless storefronts are extremely fast.

Note the phrasing. The ceiling is higher; the floor is lower. A headless storefront shipping a large JavaScript bundle for a product page is slower than a well-optimised theme. The architecture creates an opportunity, not a guarantee, and we have audited headless builds that were slower than the theme they replaced.

Complete design freedom. No theme constraints, no fighting someone else’s assumptions.

One backend, many frontends. Several brands or storefronts sharing a catalogue and order pipeline is genuinely much easier headless.

Deep content integration. If commerce and editorial content need to interleave properly — shoppable articles, content-led navigation, campaign microsites sharing the cart — headless removes a lot of friction.

Good reasons to go headless

• Multiple storefronts on one commerce backend, particularly multi-brand
• Editorial and commerce genuinely interwoven, not just a blog bolted on
• A bespoke interface the theme layer cannot express — configurators, complex filtering, unusual purchase flows
• A technically capable in-house team who will own the frontend long term
• Performance requirements where you have measured that a well-built theme cannot meet them

Bad reasons

• “We want the site to be faster.” Fix the apps and images first. That is cheaper and usually sufficient.
• “Our theme feels limiting.” A custom theme removes theme limits at half the cost and keeps the editor.
• “It’s more modern.” Architecture fashion is not a business case.
• “Our developers want to work in React.” A real consideration for hiring, and not a reason to double the build cost.

The honest cost picture

Roughly double a custom theme build for equivalent scope, and the ongoing cost stays higher permanently, because routine changes that were self-service become developer tasks.

Add storefront hosting, which the commerce platform no longer provides, and a second deployment pipeline to maintain.

For an organisation with the team and the reasons, that is money well spent. For a store that wanted a faster site, it is a very expensive route to a problem that had a cheaper solution.

How we advise

We ask two questions.

First: what specifically can you not do today? If the answer is a list of theme frustrations, a custom theme solves it for less. If the answer is genuinely architectural — multi-brand, bespoke interfaces, deep content integration — headless is the honest answer.

Second: who changes the site day to day? If marketing currently edits pages themselves and expects to continue, headless removes that, and that consequence needs accepting before the build rather than discovered after it.

What a headless project actually involves

If you have decided the reasons are real, this is the shape of the work, which differs substantially from a theme build.

Frontend framework choice. Hydrogen if staying close to Shopify’s tooling, or a framework your team already knows. The deciding factor should be who maintains it long term, not which is technically most interesting.

Data layer design. What gets fetched at build, what gets fetched per request, and what gets cached where. This is the decision that determines whether the storefront is fast, and it is easy to get wrong in ways that only appear under load.

Content management. Without the theme editor, marketing needs somewhere to edit content. That usually means adding a content management system, which is a second system to run and a cost that is often omitted from the estimate.

Cart and checkout. The cart is yours to build; checkout usually remains with the platform. The handover between them needs care, and it is where headless builds most often introduce bugs.

Preview and staging. Content editors expect to see changes before they publish. Building that is straightforward with a theme and real work headless.

Hosting and deployment. A pipeline, an environment, monitoring, and somebody who owns it.

None of that is exotic, and all of it is work that a theme build simply does not have.

Questions before committing

Who maintains the frontend in three years? Headless storefronts are ordinary web applications with ordinary maintenance needs — dependency updates, framework upgrades, security patches. If the answer is “the agency who built it”, make sure that arrangement is real and funded.

What happens to the apps you rely on? Check each one for headless support before committing, not after.

How will marketing edit content? Answer this concretely. “Through the CMS” needs to mean a specific CMS with a specific cost.

Have you measured what a good theme could achieve? If performance is the driver, get a proper measurement first. We have seen headless projects commissioned to solve a problem that an app audit and correct image handling would have solved for a fraction of the cost.

Our honest position

We build headless storefronts, and we recommend against them more often than we recommend them.

That is not caution for its own sake. It is that the reason people ask is usually performance or design flexibility, and both are more cheaply addressed by a custom theme with a disciplined app stack. The situations where headless genuinely wins — multi-brand, deep content integration, bespoke interfaces — are real and specific, and they are worth naming rather than assuming.

If you can name yours, headless is a good decision. If you cannot, it is an expensive one.