The headless commerce hype of 2021–2023 has given way to something more useful: a genuine architectural decision framework. Enterprises that rushed to "go headless" to solve problems that were never architectural have learned expensive lessons. Those who chose the right architecture for the right context have seen measurable improvements in conversion, content velocity and developer productivity.
The question is no longer "should we go headless?" — it is "what problem are we actually trying to solve, and is composable the right solution?"
"Composable commerce is a means to an end — and the end is always a better customer experience. If headless does not improve CX, it is the wrong choice regardless of what the vendor roadmap says."
When Composable Architecture Makes Sense
Composable commerce is the right architectural choice when one or more of the following conditions are true:
- Your content and commerce publishing cycles move at different speeds. If your marketing team needs daily content updates but your platform requires a release cycle to change a page template, you have a composability problem that headless solves directly.
- You operate across multiple channels with different front-end requirements. A single storefront codebase cannot efficiently serve a web PWA, a native mobile app and an in-store kiosk. Composable solves this with a shared API layer and independent front-ends.
- Your engineering team is strong and wants autonomy. Composable returns control to developers — but only if those developers have the capability to use it. An underpowered team with a headless platform often delivers worse outcomes than a well-configured traditional stack.
- Your growth strategy requires rapid international expansion. Composable architectures with a strong API gateway can support new locale and channel launches significantly faster than monolithic alternatives.
When Composable Architecture Does NOT Make Sense
The honest answer — which vendors rarely give — is that headless is not always the right answer:
- When your primary problem is UX debt, not architecture. Many "slow" commerce platforms are slow because of poor UX design — not the underlying architecture. Rebuilding in headless will not fix bad information architecture or poor conversion copy.
- When your organisation lacks the engineering capacity to maintain two systems. Composable requires ongoing investment in front-end, API and integration maintenance. If your team is already stretched, adding that complexity makes things worse.
- When your B2B process is tightly coupled to ERP data. Some B2B scenarios — particularly those involving real-time pricing, contract management and multi-level account hierarchies — perform better on tightly integrated platforms like SAP Commerce Cloud.
💡 Our recommendation: Start from the customer experience you want to deliver, identify the technical constraints preventing it, then select the architecture that removes those constraints most efficiently. This is CX¹ applied to architecture.
Concord Commerce: Composable by Design
Concord Commerce — Jarvis's own headless platform — was designed with this decision framework in mind. It offers composable architecture for organisations that need it, with pre-built connectors for SAP and Salesforce that reduce the integration overhead that typically makes headless projects expensive. For organisations that do not need full composability, Concord can be deployed in more integrated configurations without losing the API-first foundation.
The right answer is almost always "it depends" — and the only way to know what it depends on is to start from the customer experience you are trying to deliver, not from the platform brochure.