Cost & Budgeting
Engineering Practice3 min read
Headless commerce: when it earns its keep, and when it is an expensive detour
Headless solves three specific problems very well. If you do not have one of them, it adds cost and a maintenance burden for no return.
Working on something like this?
Get an estimateThe short version
- Headless earns its place for multi-storefront, genuinely custom front ends, or content and commerce from separate systems.
- If your bottleneck is page speed or integrations, headless is not the fix, and may make both worse initially.
- You are taking on a front end to maintain forever. Budget for it or do not start.
- The honest version of the question is “what specifically can we not do today?”
Headless is the default recommendation from most agencies, which should itself make you suspicious. It is also the most billable architecture available. Sometimes it is right. Often the same money spent on the existing storefront produces more revenue, which is the position we take into every eCommerce engagement.
What headless actually is
Your commerce platform keeps doing catalogue, cart, checkout, orders, and payments. You stop using its templating layer and build your own front end, talking to it over APIs.
You gain total control of the experience. You take on a front-end application to build, host, secure, and maintain for as long as the store exists. That trade is the whole decision.
The three cases where it earns its keep
1
Several storefronts, one catalogue
Multiple brands, regions, or B2C-plus-B2B off shared inventory and pricing. Maintaining four themes in parallel is genuinely worse than maintaining one front end with four configurations, and this is where headless pays back fastest.
2
The experience is the product
Configurators, made-to-order flows, quote builders, anything where the buying journey is your differentiation rather than a grid of products. Themes fight you here, and you will lose more to the fight than the rebuild costs.
3
Content and commerce live in different systems
If editorial drives a meaningful share of revenue and lives in a separate CMS, headless lets both render as one experience rather than stapling a blog subdomain onto a store.
The cases where it is a detour
- “We need better integrations.” Integrations run against the platform's APIs and are unaffected by which layer renders HTML.
- “The theme is limiting us.” Sometimes true. Frequently it means the theme was modified badly over three years. A rebuild on the same platform is a fraction of the cost.
- “Our competitors did it.” They may also regret it. You cannot see their maintenance burden from outside.
- Small catalogue, small team, no in-house engineering. You will own an application with nobody to own it.
What it costs beyond the build
None of these are reasons not to do it. They are reasons to know what you are signing up for, and to staff it.
The question to ask instead
What specifically can we not do today, and what is it costing us?
If the answer is concrete (“we cannot run three regional storefronts without three theme codebases”, “our configurator needs state the theme cannot hold”), headless is likely correct and the business case writes itself.
If the answer is “it would be more modern”, spend the budget on page speed, merchandising, and the checkout instead. Those move revenue reliably. If the answer is “our cloud bill tripled and peak day frightens us”, that is a cloud and DevOps problem wearing a replatform costume.
If you do go headless
Decide these before writing code
- Rendering strategy per template (static, server-rendered, or client), and why for each — this is most of what choosing Next.js actually decides
- Who owns the front end in year two, by name
- How merchandisers preview unpublished changes
- Which platform features you are rebuilding and which you are dropping
- A Core Web Vitals budget, enforced in CI so regressions fail the build. If you have no pipeline to enforce it in, that is a DevOps conversation first
That last one matters more than it sounds. The most common headless outcome is a site that launches fast and degrades over eighteen months, because nothing stops it. A performance budget in the pipeline is the only reliable defence.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
Three cases: you run several storefronts off one catalogue and are maintaining themes in parallel; the buying experience itself is your differentiation, such as a configurator or quote builder; or content and commerce live in separate systems and both drive revenue. Outside those, a well-built native storefront is usually faster to ship and cheaper to run.
Not inherently. It moves responsibility for performance from the platform to your team. A poorly built headless storefront is slower than a well-tuned native theme. If speed is the problem, fix images, third-party scripts, and caching first. That work is cheaper and frequently resolves the issue without a replatform.
Maintaining a front-end application and its dependencies indefinitely; rebuilding platform features that used to come free with the theme, such as search, faceting, and promotions; building preview tooling for merchandisers; owning SEO rendering and structured data; and debugging across two systems on every incident.
The rendering strategy for each template type and the reasoning behind it, who owns the front end in year two by name, how merchandisers preview unpublished changes, which platform features you are rebuilding versus dropping, and a Core Web Vitals budget enforced in CI. Without that last one, headless sites reliably degrade over the first eighteen months.