Headless or not: a decision guide that costs us money to write
Headless is a cost you pay for a freedom most shops never use. Here is when it genuinely pays, when it is an expensive way to rebuild the standard storefront, and the team-size question nobody asks first.
Photo: free stock photography (Unsplash licence) — see imprint
Headless is not an upgrade — it is a trade
The word arrives in meetings with an implied direction, as though there is a ladder and headless is the rung above where you are. There is no ladder. Decoupling your frontend from your shop backend buys you exactly one thing — freedom over what the frontend is and where it runs — and charges you for it in code you now own, a second deployment pipeline, and every feature the standard storefront gave you for free and now does not.
That second list is longer than anyone expects at kickoff. Checkout with its payment states and edge cases. Customer accounts, address books, order history. The B2B pricing and tax logic. Search, filters, pagination, breadcrumbs. Cookie consent. SEO metadata, canonicals, structured data, the sitemap. None of it is impossible. All of it is work you were not doing last month, and it produces no new revenue on the day it ships, because your customers already had all of it.
When it genuinely pays
There are real cases, and they share a shape: the freedom is something you will actually spend. Multi-channel is the clearest — if the same catalogue, cart and customer must appear in a shop, a native app, an in-store kiosk and a partner portal, then a shared API is not an indulgence, it is the only sane architecture. Building four frontends against four templated backends is worse in every way.
The second real case is an existing frontend team. If you already employ three or four people who write React or Vue every day, who own a component library and a design system, then headless removes friction they feel daily and hands work to people you are already paying. The third is genuinely extreme design or interaction requirements — a configurator, an unusual buying flow, something the template system fights you on every sprint. Note what all three have in common: the freedom gets used, by people who exist, for a reason you can name in one sentence.
The team-size reality nobody puts in the proposal
This is the part that decides most projects and is discussed last. A decoupled storefront is a permanent software product. It needs someone who can upgrade a JavaScript framework without a week of panic, someone who understands server-side rendering well enough to keep Google happy, and someone who will still be there in eighteen months when a dependency goes end-of-life. That is not a launch cost. That is a headcount.
Our blunt threshold: if you cannot name the two people who will own that frontend next year, do not go headless. Not 'we will find an agency' — name them. A shop with one part-time developer and a maintenance contract will find that a decoupled architecture converts every small change into a coordination problem across two codebases. The company that suffers most from headless is the one that chose it to look modern to a board.
- Can you name two people who own the frontend in twelve months?
- Is there a second channel that is funded, not just discussed?
- Can you name the thing the standard storefront actually prevents?
- Are you prepared to rebuild checkout, accounts and SEO plumbing?
- If the answer to any of these is soft, the standard storefront wins.
The most common outcome: an expensive rebuild of what you had
We have been called in to rescue enough of these to describe the arc from memory. Month one is euphoric — the product listing is fast and beautiful and the team is proud. Month four is checkout, and checkout is where all the ugly reality lives: payment provider redirects, error states, address validation, the discount that only applies to one customer group. Month seven the shop launches and the conversion rate is slightly worse than the old one, because a thousand small behaviours that the standard storefront had quietly got right were not in the specification.
The tell is a business case that talks about speed. A decoupled frontend can be very fast, but so can a well-cached standard storefront, and the second one costs an afternoon rather than seven months. If the only argument for headless is performance, you are about to spend a six-figure budget on something a cache configuration and a fixed N+1 query would have delivered by Friday.
The middle path most shops should take
You do not have to choose between a template and a full rebuild. The API that makes headless possible is there whether you use it for your main storefront or not — so use it for the thing that actually needs it. Build the configurator as a decoupled component inside the standard shop. Feed the partner portal from the API. Serve the app from it. Keep the checkout that already works, in the system that already maintains it, and spend your budget where the freedom earns something.
This is the boring answer and it is right far more often than the exciting one. It also has a property the full rebuild lacks: if the configurator is a success, you have learned something for a fraction of the price, and the full decoupling is still available next year with better information. A profitable shop on a standard storefront does not have to go headless this year. Possibly not ever.
| Your situation | Verdict | Why |
|---|---|---|
| One shop, one country, part-time dev | Standard storefront | You would own a product you cannot staff |
| Shop + app + kiosk + partner portal | Headless | A shared API is the only sane architecture |
| In-house React/Vue team already | Headless is defensible | Work goes to people you already pay |
| One weird configurator, rest normal | Decouple that one component | Buy the freedom only where you spend it |
| The site feels slow | Not a headless problem | Cache and query fixes cost an afternoon |
- Headless buys freedom over the frontend and charges you in code you now own.
- If you cannot name the two people owning the frontend next year, do not go headless.
- Performance alone is never the argument — a cache fix is cheaper by two orders of magnitude.
- Decouple the one component that needs it, not the shop that already works.
Frequently asked questions
It can be, but a well-cached standard storefront can be just as fast, and getting there costs days rather than months. If performance is your only reason, profile the shop first — most slow shops are slow because of cache misses or queries in a loop, and both are fixable without rearchitecting anything. Rebuilding the frontend to fix a database problem is an expensive misdiagnosis.
You need at least two people who can own a JavaScript frontend as a permanent product — framework upgrades, server-side rendering, dependencies going end-of-life. If those two people do not exist and are not budgeted, a decoupled storefront turns every small change into a two-codebase coordination problem. An agency retainer can supplement that ownership, but it cannot replace it.
The build is the smaller half. You are rebuilding checkout, customer accounts, search, filters, SEO plumbing and consent — features you already had and that produce no new revenue on launch day. Then you own a second codebase forever. Ask for the twelve-month running cost, not the project price; the running cost is what makes or breaks the decision.
Yes, and for most shops this is the right answer. The API exists whether or not your main storefront uses it, so build the configurator, the partner portal or the app against it and leave the checkout in the system that already maintains it. You get the freedom exactly where you will spend it, at a fraction of the cost, and the full decoupling stays available later.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer