The Composable Commerce Promise
Composable commerce - assembling a commerce platform from best-of-breed components connected via APIs - promises flexibility, vendor independence, and the ability to evolve each capability independently.
The promise is real. So is the cost.
The Decision Framework
Before recommending headless architecture to any client, I ask four questions:
1. Do you have multiple frontends? If you have a web storefront, a mobile app, a kiosk, and a B2B portal - headless pays for itself. If you have one web storefront, a monolith is almost certainly cheaper to operate.
2. Do your frontend and backend teams deploy independently? Headless architecture only delivers velocity if the teams consuming the APIs can ship without coordinating with the teams producing them. If they always deploy together, you have a distributed monolith.
3. Do you need to replace individual capabilities without rebuilding the whole platform? This is the core value proposition of composable. If your checkout logic is stable but your PIM is a mess, composable lets you replace the PIM without touching checkout.
4. Do you have the engineering maturity to operate distributed systems? Headless commerce means API contracts, versioning, distributed tracing, and eventual consistency. Teams that struggle with a monolith will struggle more with a distributed system.
The Hidden Costs
The costs that are consistently underestimated:
- API contract management - every integration point is a contract that must be versioned and maintained
- Distributed debugging - a checkout failure that spans five services is harder to diagnose than one that spans one
- Organisational alignment - composable architecture requires organisational composability. Teams that are tightly coupled will recreate that coupling in their APIs
When the Monolith Wins
For a single-market, single-channel retailer with a stable product catalogue and a team of fewer than 20 engineers: a well-structured monolith will outperform a composable architecture on every metric that matters - time to market, operational cost, and developer experience.
The goal is not to be headless. The goal is to build the right system for the problem.