Headless commerce: worth it, or expensive?

Headless commerce is the only architecture decision we get asked about by people who cannot yet say what problem it would solve for them.

That is not a criticism of anyone. It has been marketed extremely well, the demos are genuinely impressive, and the argument sounds airtight: decouple your storefront from your commerce engine, and you get freedom, speed and a future-proof stack. Every word of that is true. What the pitch leaves out is the price, and the price is not mostly money.

We have built headless storefronts, and we have talked at least as many brands out of one. Here is the honest threshold.

What it actually means, minus the marketing

A conventional store is one system. The commerce engine holds your products, cart, checkout and orders, and it also renders the pages. Your theme is a set of templates inside that system.

Headless separates the two. The commerce engine keeps doing commerce and exposes it through an API. The storefront becomes a separate application — usually a JavaScript framework — that asks the API for data and renders whatever it likes. Checkout is often the exception and stays with the platform, because rebuilding a checkout is a bad idea for reasons we will come back to.

The important consequence is buried in that description. In a conventional store, the platform ships a storefront and you customise it. In a headless store, nobody ships a storefront. You build one, from nothing, including all of the parts nobody demos.

The three reasons that genuinely justify it

One: you have several front ends and one commerce core. A website, a kiosk in retail stores, an in-app shop, a partner-embedded storefront, a marketplace integration. When commerce has to be consumed by more than one experience, an API-first core is not a preference, it is the correct architecture. This is the strongest case and the least common.

Two: your experience layer genuinely cannot be expressed in a theme. Not “we want an unusual layout” — themes handle unusual layouts. This means real interactivity: a configurator with live pricing and 3D preview, a booking-plus-product hybrid, a personalised catalogue that changes structurally per user, an editorial experience with commerce woven through it rather than beside it.

Three: your content platform is the primary experience and commerce is a component of it. Media businesses that sell, brands with enormous editorial estates, community platforms with a shop. Here the commerce engine is genuinely a service rather than the site, and treating it as one is honest architecture.

That is the list. Notice what is not on it.

What is not a reason, however good it sounds

“It will be faster.” Sometimes, at the margin, in the hands of a good team. But most slow stores are slow because of images, third-party scripts and app bloat, and every one of those problems is fully portable to a headless build. We have audited headless storefronts that were slower than the theme they replaced, because a framework does not stop anyone adding six tracking pixels. If speed is the goal, fix what is actually making the store slow — it costs a fraction as much and works.

“It’s future-proof.” A bespoke front end built on a framework that moves fast is not obviously more future-proof than a theme on a platform with a commercial interest in keeping it working. You are trading one dependency for a different one, and the new one has a shorter support horizon.

“Our developers prefer it.” A legitimate consideration for hiring and morale, and not an architecture decision. The question is who maintains it in three years, not who enjoys building it this year.

“Our competitor did it.” You cannot see their maintenance bill.

“We want full design control.” Themes give more control than people think, and the last ten percent of design control is the most expensive ten percent in commerce.

The threshold test

Five questions. Fewer than three yeses, and a well-built theme will serve you better.

1. Do you need to serve commerce to more than one front end? Not “might one day”. Do you have a second surface, funded, on a roadmap.
2. Is there a specific interaction your platform’s templating genuinely cannot express? Name it in one sentence. If you cannot, the answer is no.
3. Do you have in-house engineers, or a long-term agency relationship, who will own this for three years? Not for the build. For the life of it.
4. Is your traffic or catalogue at a scale where platform rendering is a measured constraint? Measured, not assumed.
5. Is content architecture a first-class requirement rather than a blog? Structured content, multiple types, editorial workflow, relationships between content and products.

Most brands under a few million in revenue answer no to all five, and are being quoted for headless anyway.

What you take on, in detail

This is the section the pitch decks skip, and it is where the cost lives.

Every template, from nothing. Product, collection, search, account, order history, wishlist, gift cards, policy pages, error states, empty states, out-of-stock states. A theme ships all of these, considered and tested. A headless build ships whatever you paid for, and the unglamorous ones get cut.

Your own SEO surface. Server-side rendering, metadata, canonicals, structured data, sitemaps, pagination handling. All solvable, all now your job, and all easy to get subtly wrong in ways that cost organic traffic for months before anyone notices.

Preview and publishing. Marketing wants to see a page before it goes live. In a theme, that is built in. In a headless stack it is a feature somebody has to implement across two systems.

Merchandising tools. The drag-and-drop section editor your team uses to build a campaign page does not exist any more unless you build it. This is, in our experience, the single most common source of regret — the store gets faster and the marketing team gets slower, and nobody predicted that trade.

App compatibility. A large part of what makes platform ecosystems valuable is that apps inject themselves into the storefront. In headless, most of them cannot. Every app you rely on for a front-end behaviour needs to be re-implemented, replaced with an API-level equivalent, or dropped.

Two deployment pipelines, two sets of dependencies, two places to look when something breaks. Plus the ongoing framework upgrades, which are not optional and are not small.

The maintenance question, which is the real one

A theme has a floor. If you stop investing in a themed store, it keeps working. It gets stale, it falls behind, but it serves pages and takes orders indefinitely.

A bespoke front end does not have that floor. Dependencies age, the framework releases a major version, a build breaks, a rendering service changes its pricing. Left alone for eighteen months, it degrades in ways a theme does not.

So the honest question is not “can we build this” — you can, and we can. It is: will there still be a budget line for front-end engineering in year three? Brands that answer that confidently do well with headless. Brands that treat it as a project with an end date end up rebuilding on a theme in four years, which we have been hired to do more than once.

The middle options

Because this is presented as a binary, the good in-between answers get skipped.

Modern theme architecture. Platform themes have improved enormously. Sections, blocks, app extensions and better data access cover the great majority of what brands actually asked headless for, while keeping the merchandising tools and the maintenance floor.

Headless for one surface only. Keep the main storefront on a theme and build a bespoke front end for the one thing that genuinely needs it — the configurator, the kiosk, the embedded shop. You get the capability without turning your entire storefront into a bespoke application.

Content-led hybrid. Keep commerce on the platform and put the content estate in a proper CMS, joined carefully. This is the architecture we recommend most often to content-heavy brands, and we describe it in WordPress to Shopify. It solves most of what people want from headless at a fraction of the risk.

Progressive enhancement. Enrich specific parts of a themed page with a modern front end where it earns its place. Unglamorous, effective, cheap.

If you are going to do it, do this

For the brands where the answer is yes, four things separate the successful builds from the regretted ones.

Keep the platform’s checkout. Almost always. The checkout is the most optimised, most tested, most compliance-sensitive part of the stack, and rebuilding it is how a project trades a conversion rate for an architecture diagram.

Design the merchandising experience before the customer experience. Decide how a marketer builds a campaign page on day one, not in month five. If the answer is “they ask a developer”, you have built something your business will resent.

Set a performance budget and enforce it. A headless build makes it easy to ship a large JavaScript bundle. Agree the numbers up front and fail the review when they are exceeded.

Budget the second year. Write down what front-end maintenance costs annually and get it approved before the build starts. If nobody will sign that, the project is not funded — it is only half funded, and the half that is missing is the half that keeps it alive.

Where the speed argument actually holds, and where it does not

Worth separating, because there is a real technical claim buried under a lot of marketing.

Where it holds. A well-built modern front end can render a page shell instantly and stream the rest, prefetch the next likely navigation, and avoid a round trip to an origin server on every click. On a store where people browse deeply — long collection pages, lots of filtering, high pages-per-session — that architecture genuinely feels faster, and the feeling is worth money.

Where it does not. Most commerce sessions are shallow. Somebody arrives on a product page from an ad or a search result, and either buys or leaves. For that journey, what matters is how fast the first page renders and how heavy it is — and a themed page with disciplined images and few third-party scripts beats a heavy headless bundle every time.

So the speed argument is really an argument about session shape. Deep browsing, many navigations, an app-like experience: headless helps. One page, one decision: it mostly does not, and the effort would have been better spent on images.

Measure your own pages-per-session before anyone uses speed as an argument. If it is close to two, the architecture is not your bottleneck.

The failure mode we see most

It is remarkably consistent, and it does not look like failure while it is happening.

The build goes well. The site launches and it is fast and it looks superb. Six weeks later marketing needs a campaign page and files a ticket. Three months later there is a backlog of small storefront changes because everything requires a developer. At six months a required app cannot be used because there is no front end for it. Somewhere in year two a framework upgrade takes a fortnight, and the retainer that was meant to cover improvements is spent on maintenance instead.

Nothing broke. The store simply became slower to change than the business needed, and the cost showed up as missed campaigns rather than as an invoice.

You can design that away — by building merchandising tools, budgeting maintenance properly, and being honest about who can change what. But it has to be a decision at the start, because by the time it is visible you have already built the thing.

The cost, honestly

Nobody publishes headless prices, so here is the shape of it rather than a number.

The build is commonly two to three times a comparable themed build, and that is not the important number. The important number is the annual one, because a bespoke front end has a permanent cost of ownership that a theme does not. When we quote both, the three-year totals are usually further apart than the build totals — the same arithmetic we apply to replatforming budgets generally.

There is one honest counterweight. If you are already paying for in-house front-end engineers, a large part of that annual cost is a salary you are paying anyway, and the calculus shifts considerably. Headless is much more defensible for a brand with an engineering team than for a brand with an agency.

Four questions to ask whoever is proposing it

If somebody has recommended headless, these four answers will tell you whether the recommendation was made for you or for them.

“Which of my requirements cannot be met by a theme?” A good answer is specific and short. A bad answer is a list of adjectives.

“How will my marketing team build a landing page in this?” Watch for the pause. If the honest answer is “they will ask us”, that is a permanent cost and it should be priced.

“What is the annual maintenance figure, and what happens if we do not spend it?” Any proposal without this number is incomplete.

“Which of your headless builds is still running, unchanged, after three years?” The most useful question in the set, and the least often asked.

What it comes down to

Headless is a correct architecture for a small number of businesses and an expensive one for everybody else. The deciding factor is almost never the storefront you can build. It is whether you have a genuine second surface, a genuine interaction that a theme cannot express, and a genuine, funded, ongoing engineering capability.

If you have all three, it is a good decision and we would help you make it. If you have one, look hard at the middle options. If you have none, a well-built theme with a serious performance budget will beat a mediocre headless build on every metric you care about, including the ones headless is sold on.

Not sure which side of the line you are on? Send us what you are trying to build through the contact form — one paragraph is enough. We will tell you whether it needs a headless architecture, or whether it needs three days of work on the theme you already have. We have talked more brands out of this than into it.

You can also read Shopify Plus versus a custom build, or what actually moves the needle on commerce performance.