E-commerce · Shop systems
Headless & Composable Commerce: When the Freedom Pays Off
Headless commerce pros and cons: what the freedom really costs, monolith vs composable compared – and a clear decision path for choosing between them.
By Boaz Lichtenstein
“Headless” is one of the most misunderstood words in e-commerce. It sounds like the future, but it’s often sold without a glance at the cost. Time for a sober assessment: what does it mean technically, what does it really cost – and who is the move actually worth it for.
Key takeaways
- Headless separates frontend and backend via APIs; composable goes further and combines best-of-breed services instead of a single all-in-one platform.
- The freedom has a price: without an in-house or reliably available external dev team, composable quickly ends up more expensive than the standard it was meant to replace.
- Composable pays off mainly with multiple touchpoints, extreme performance requirements or very specific UX needs – not as a default starting point.
- Monolith-first remains the right order for most retailers, especially now that AI-assisted development makes standard customisation cheaper than before.
- Total cost of ownership is rarely driven by licences – it’s driven by ongoing integration maintenance between services.
What headless and composable actually mean
Headless separates the frontend (the storefront customers see) from the backend (product data, basket, checkout logic); communication runs over APIs instead of a fixed template system. Composable goes a step further and replaces the all-in-one platform with a combination of individually chosen best-of-breed services.
In concrete terms: instead of one platform delivering search, content management and checkout from a single source, you combine search from provider A, content management from provider B and checkout from provider C – each connected via its own interface. The result is maximum flexibility, but also maximum responsibility for making the parts work together. Every additional service is another contract, another API version, another point where something can break.
Monolith vs composable compared
The two architectures don’t differ by degree – they differ fundamentally in team requirements, time horizon and risk profile:
| Criterion | Monolith | Composable |
|---|---|---|
| Time to market | Weeks | Usually several months |
| Team requirement | A standard agency is usually enough | In-house or highly experienced external dev team needed |
| Flexibility | Limited to the platform’s boundaries | Very high, but you orchestrate it yourself |
| Ongoing costs | Predictable (licence plus maintenance) | Variable, dominated by integration upkeep |
| Failure risk | One vendor, one support channel | Several vendors, shared responsibility |
No row in this table makes either architecture better per se – it just shows what each is built for. The last row stands out in particular: with a monolith, failure risk is concentrated but clearly addressable – one vendor, one contract, one escalation path. With composable, it’s distributed, but harder to manage as a result, because in a real incident you have to coordinate several contracts, several support windows and several escalation paths at once.
The honest price
What tends to get glossed over in sales pitches: with headless, you take on the responsibility a monolithic platform used to carry for you. Someone has to build and maintain the frontend, someone has to maintain every integration, and when something breaks there’s no longer a single support channel – there are several vendors who can point the finger at each other.
The rule of thumb is therefore simple: without your own dev team – in -house or as a reliable external partner – composable isn’t a good idea. The freedom is real, but it has a price in person-days, not just in licence fees. If you want to calculate total cost of ownership realistically, you should price in those person-days just as carefully as the licence costs of the individual services – more on that calculation logic in our article on unit economics in e-commerce.
A typical failure scenario makes the risk tangible: a third-party search service changes an API response format without much notice, the checkout system reports a maintenance gap at the same time, and in the meantime your storefront shows products without current prices. On a monolithic platform, that would be a single support case. With composable, it’s potentially two tickets with two vendors whose respective responsibility still needs clarifying – while the store stays live the whole time.
The most common mistakes when switching
Five patterns crop up again and again in failed or overpriced composable projects:
- Starting the migration before building the team: commissioning the project first and only then looking for developers – the order should be reversed.
- Introducing too many services at once: replacing search, content, checkout and personalisation all at the same time instead of step by step – this multiplies the risk instead of spreading it.
- Not naming an owner for orchestration: if nobody is explicitly responsible for how the services work together, every fault gets stuck in the no-man’s-land between vendors.
- Taking performance promises at face value: “headless is faster” is only true with clean execution – see the FAQ.
- Underestimating SEO and content migration: URL structure, redirects and rendering strategy need their own migration plan, not a footnote in the project plan.
When it pays off
Composable pays off when the standard demonstrably hits its limits – not the moment it merely feels uncomfortable. Three signals argue for the switch: multiple touchpoints such as app, web and in-store kiosk that need the same product data in real time; extreme performance requirements, where every tenth of a second of load time costs revenue (see our article on page performance and conversion); or very specific UX requirements that no standard theme can map. Conversely, the switch is a bad idea if: you have a small or mid-sized team without dedicated development resources, a range without complex multi-channel requirements, or a standard system that so far only feels “vaguely tight” without any concrete requirement actually failing on it. In all these cases, composable buys you degrees of freedom a monolith structurally can’t offer – but only if those degrees of freedom are actually needed.
The hybrid middle path
Between a pure monolith and a full composable stack, a third path now exists: many established platforms now offer native headless APIs or composable extensions that can be switched on selectively, without replacing the entire backend. This significantly lowers the barrier to entry, because you retain some of the platform’s safety net.
In concrete terms: a retailer might keep checkout and inventory management on their existing platform, but selectively introduce a headless frontend layer for product pages – say, for a particularly fast landing-page campaign or a new app. This middle path is rarely the end goal of a composable journey, but it’s often the smartest first step: it shows whether the team can actually handle the extra complexity before the whole architecture is put up for debate.
It’s important to treat the hybrid approach deliberately as a learning phase, not a permanent state. Anyone who keeps oscillating between two architectures indefinitely racks up technical debt on both sides instead of consistently mastering either one – the middle path is meant to be a bridge, not a new home.
The decision path
For most retailers, monolith-first remains the right order – and that choice is made differently today than a few years ago, because AI-assisted development changes a lot here too: as already described in our Shopware vs Shopify comparison, the cost of custom adjustments to standard systems is falling significantly, which reduces the pressure towards composable. Composable is something you earn once the standard demonstrably becomes too tight – not the starting point for a new business. Anyone who starts with a monolith and deliberately keeps the architecture modular can later swap out individual building blocks selectively, instead of having to assemble everything themselves on day one.
The bottom line
Headless isn’t a status symbol – it’s an architecture decision with clear costs and clear benefits. Anyone who honestly answers the question “do we have the team to carry this freedom?” makes the right choice almost automatically, regardless of whatever happens to be trending. The most pragmatic next step for most stores: keep working with your existing monolith until a concrete requirement demonstrably fails on it, rather than switching on principle.