Headless Commerce: What It Actually Costs, And When It Pays

There is a strange thing about researching headless commerce. Read ten articles on whether it lowers total cost of ownership and you will find that roughly ten of them were published by companies that sell headless commerce, or by an industry body whose members do.

That does not make the argument wrong. Vendors often understand their category better than anyone. But a buyer weighing a seven figure architecture decision should know that the entire evidence base they are reading was written by people with one answer already prepared.

So here is an attempt at the other version. Headless commerce works. It is genuinely better for a specific set of businesses. And for most mid market stores it is an expensive answer to a question they do not have. If you have not yet settled whether to move platform at all, when to replatform is the question that comes first.

Headless, composable and MACH are three different claims

These three words get used as synonyms and they are not, which matters because a vendor can truthfully describe a product as headless while giving you almost none of what you were promised by "composable".

Headless is one architectural decision: the storefront is decoupled from the commerce backend and talks to it over an API. That is the whole claim. Your catalogue, cart, pricing and orders still live in one system. You have simply replaced its templating layer with your own frontend.

Composable is a procurement strategy. Instead of buying one platform that does everything moderately well, you assemble the stack from specialists: one vendor for the commerce engine, another for search, another for content, another for payments, another for order management. Headless is a precondition for this, since you cannot swap out the search component of a system that has no API boundary around it. But being headless does not make you composable. Plenty of stores run a decoupled frontend against a single monolithic backend, and that is a completely reasonable place to stop.

MACH is the set of design principles the composable approach is usually built on: microservices, API first, cloud native, headless. It is maintained and promoted by the MACH Alliance, an industry body that certifies vendors against those criteria. Useful as a shorthand. Worth remembering that it is a membership organisation whose members sell the architecture it defines.

The practical consequence: when a vendor says headless, ask which of the three they mean, and specifically ask how many separate contracts and support relationships the proposal implies. That number, more than any technical detail, predicts what the next three years feel like.

What decoupling actually buys you

The benefits are real. They are also conditional, and the conditions are where the honest conversation lives.

Frontend freedom. You can build the storefront in whatever framework your team knows, ship it on a CDN, and change it without touching commerce logic. This is the benefit that materialises most reliably.

The condition: it pays when you have a frontend team. If your storefront changes are made by a merchandiser in a theme editor, decoupling removes their ability to do their job and routes every change through an engineering backlog.

Performance headroom. A statically rendered storefront served from the edge can be very fast, and Core Web Vitals thresholds are achievable with room to spare, with Largest Contentful Paint under 2.5 seconds and Interaction to Next Paint under 200 milliseconds.

The condition: headroom is not a result. A decoupled storefront that fetches pricing, inventory and personalisation on every page load can easily be slower than the monolith it replaced, because you have added a network hop to operations that used to be a local database call. The performance win comes from caching strategy, and caching strategy is now your problem rather than your platform's.

Multi experience delivery. One commerce backend serving a website, a mobile app, an in store kiosk and a marketplace feed, without duplicating business logic.

The condition: you actually have more than one experience. This benefit is close to zero for a single website, and it is the single most oversold item on the list.

Component level replacement. Unhappy with search? Replace search, not the platform.

The condition: this requires genuine composability, meaning contracts and data ownership arranged so that replacement is possible. Many stores that call themselves composable have integrations tangled enough that swapping any one component is its own migration.

Independent deployment. Frontend and backend release on separate cycles, so a storefront change does not wait for a platform release window.

The condition: you need the deployment discipline to match, which means proper continuous integration, automated tests and observability across service boundaries. Without those, independent deployment mostly means independent breakage.

The costs that only appear after go live

Build cost is the number in the proposal. Run cost is the number that decides whether the decision was right, and it has six lines that rarely appear in a vendor comparison.

Multiple vendor relationships. Each component is a contract, a renewal, a support process and a price rise. Five specialist vendors mean five sets of terms, five service level agreements with different definitions of an incident, and five roadmaps you do not control. Procurement and legal effort scales with vendor count, and so does the annual increase.

Integration maintenance. The glue between components is code you own. When the search vendor deprecates an API version, that is your sprint. Across five vendors, breaking changes arrive somewhere in the stack constantly.

Observability across boundaries. In a monolith, a slow product page is one system to inspect. Across six services it is a distributed tracing problem, and distributed tracing is a tool, a cost and a skill you now need. OpenTelemetry, formed in 2019 when OpenTracing and OpenCensus merged, is the usual answer, and adopting it is a project of its own.

On call. This is the one that surprises people. A single vendor platform means one number to call at 2am, and the vendor owns uptime. A composed stack means your team owns the interaction between components even when each component is healthy, and "each vendor says their part is fine" is a real and common failure mode. Someone has to be paid to be awake for that.

Duplicated data. Product data will end up in the commerce engine, the search index, the content system and probably a feed for marketplaces. Keeping four copies consistent is an ongoing engineering commitment with its own failure modes.

Version drift. Independent services move at independent speeds. Without deliberate effort you accumulate a stack where three components are current and two are two years behind, which is where the security exposure sits.

None of this makes composable a bad choice. It makes it a choice with an operating budget, and the operating budget is the part that gets left out of the business case.

What this looks like at 2am

An example, and a common one. Customers report that some product pages show the wrong price. Not all of them, and not consistently.

On a monolith, price lives in one table. You query it, you find the bad row, you fix it, and the whole investigation is one system deep.

On a composed stack, price might be authored in the commerce engine, cached in the search index that powers your listing pages, cached again at the CDN, and overridden by a promotions service that applies rules at request time. Four places, four owners, four caches with different invalidation rules. The commerce engine reports correct data. The search vendor reports a healthy index. The CDN reports normal operation. Every component is telling the truth, and the page is still wrong, because the fault is in the interaction between them and nobody sells a support contract for that.

The work of resolving it is yours. So is the work of building enough tracing to make it resolvable in under an hour rather than over a weekend. That capability is not optional at this architecture, and it does not appear on a licence quote.

Who has to run it

The constraint that actually stops mid market stores is not money. It is people.

A monolithic platform lets a small team run a large store, because the vendor absorbs the operational complexity. A composed stack transfers that complexity to you in exchange for control. That trade is excellent when you have engineers to spend and terrible when you do not.

A realistic minimum for a composed stack in production is a frontend capability, a backend or integration capability, someone who owns infrastructure and deployment, and enough coverage that no single person is the only one who understands a critical path. Below roughly that, you have built a system your team cannot safely operate, and the first serious incident will make that obvious.

There is also a hiring asymmetry worth thinking about. Developers who know a mainstream commerce platform are relatively easy to hire. Developers who know your specific composition of six vendors do not exist, so every hire has a long ramp regardless of seniority.

Ask one question before committing: if the engineer who designed this leaves in eighteen months, can the rest of the team keep it running? If the honest answer is no, the architecture is a risk to the business rather than an advantage.

When headless is the right call

Some businesses should absolutely do this, and they tend to share recognisable traits.

You genuinely have several front ends. Website, native app, kiosk, marketplace, wholesale portal. The moment business logic would otherwise be duplicated in three places, decoupling stops being architecture fashion and starts being basic hygiene.

Your frontend is a competitive asset. Brands whose shopping experience is genuinely differentiated, with custom configurators, rich editorial commerce or unusual interaction models, hit template limits early and hard. If your design team is regularly told no by the platform, that is a real constraint.

One component is business critical and the platform's version is weak. Search is the usual example. For a large catalogue, relevance directly drives revenue, and a native search that cannot handle synonyms or merchandised rules is a measurable cost. Replacing that one component is a strong, contained case for decoupling.

Scale genuinely exceeds what a single platform handles well. Very large catalogues, very high traffic concurrency, or global operations with regional data requirements.

You already have the engineering organisation. If you employ a platform team today, the operating cost is marginal rather than new, which changes the arithmetic completely.

Two or more of these, and headless deserves serious evaluation. One of them, and the honest answer is usually to solve that one thing without rearchitecting everything around it.

When a monolith is the better engineering decision

This is the section most articles skip.

A single storefront and a small team. The multi experience benefit is zero and the operating cost is not. You are paying for optionality you will not use.

Merchandiser led change. If the people who change the site every day are not engineers, decoupling makes your organisation slower. Every banner, layout tweak and landing page becomes a ticket. Teams discover this about four months after launch and it is genuinely hard to reverse.

Standard commerce requirements. If what you sell fits a mainstream catalogue model and your checkout is conventional, a modern monolith does that well, and it does it with one support contract.

No appetite for operational ownership. Wanting your ecommerce platform to be somebody else's problem at 2am is a legitimate business position. Say it out loud during vendor selection, because it eliminates half the options immediately and saves everyone time.

The monolith is not the safe old choice. For a business with these characteristics it is the correct choice, and choosing it deliberately is a sign of a mature technical decision rather than a conservative one.

The middle path most stores should look at first

There is a large gap between a fully composed MACH stack and a stock theme, and most stores belong somewhere in it.

Decoupled frontend, single backend. Take the frontend freedom and the performance headroom, keep one commerce vendor, one contract and one place to call. You give up component replaceability and keep most of the practical benefit. For a store whose main problem is that the theme layer is limiting design, this solves the actual problem.

Monolith plus one specialist component. Keep the platform, replace only the piece that is genuinely weak, usually search, sometimes content. One integration to maintain instead of six. This is the highest return move available to most mid market stores and it is almost never what gets proposed, because it is not a project anyone can sell as a transformation.

It is worth being concrete about what that swap involves, because it sounds harder than it is. You feed your catalogue into a dedicated search service, point the listing and search templates at it instead of the platform's native query, and keep everything else untouched. Cart, checkout, payments, order management and the admin your team already knows all stay exactly where they are. The integration surface is one index feed and one query endpoint. Scope is typically weeks rather than quarters, and if it does not deliver, reverting means pointing two templates back at the native search.

Compare that with the full composable version of the same benefit, which is the same search improvement plus five new vendor relationships and an on call rota. The improvement to relevance, which was the actual goal, is identical in both.

Progressive decoupling. Move one route at a time. Start with the product listing pages, keep checkout on the platform, and decide whether to continue based on what the first slice taught you. It is slower and it is far easier to stop.

That last option matters more than it sounds. Architecture decisions made all at once cannot be evaluated, because by the time you know whether it was right, reversing it costs more than continuing. Decisions made in slices stay reversible for longer, and reversibility is worth paying for.

How to test the decision before you commit

Before signing anything, run a bounded evaluation. Four weeks is usually enough.

Week one, name the constraint. Write down the specific thing the current platform prevents. Not "we need more flexibility", but something falsifiable: "we cannot render a configurator on the product page without a full page reload". If nobody can write that sentence, stop, because there is no problem statement to solve.

Week two, build the thinnest possible slice. One real page, real data, real API calls, deployed. Not a prototype on mock data, which proves nothing about the thing that will actually hurt, namely latency and cache behaviour under real conditions.

Week three, measure it honestly. Time to first byte and Largest Contentful Paint on a cold cache, on a mid range mobile device on a normal connection. Google publishes the thresholds, so you have a number to pass rather than a feeling to argue about: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1, each judged at the 75th percentile of real visits. Compare against the same page on the current platform. A decoupled page that is slower than the one it replaces is common enough that this check is the whole point.

Week four, cost the run, not the build. Ask each vendor in the proposed stack the same four questions: what does support cost when we exceed the standard tier, what is your incident response commitment in writing, what is the historical annual price increase, and what does exit look like including data export format. The answers vary enormously and rarely appear in a sales deck.

Then decide. If the slice was fast, the constraint was real and the run cost is affordable, you have a genuine case. If the slice was slower and nobody could name the constraint, you have saved yourself a year.

Architecture should follow the constraint, not the conference talk. Headless commerce is a serious, capable approach that solves real problems for businesses with several front ends, differentiated experiences or engineering teams already in place.

For everyone else, the honest recommendation is usually smaller and less exciting: fix the one component that is actually weak, keep one vendor accountable for uptime, and spend the saved budget on the catalogue and the checkout, which is where the revenue is anyway.