HEADLESS
A separated frontend and backend.
The customer experience is decoupled from the commerce engine through APIs. The backend may still be a hosted platform or it may be an independently owned commerce system.
01
WHAT IS HEADLESS COMMERCE?
DEFINITION / ARCHITECTURE / OWNERSHIPHeadless commerce is an ecommerce architecture in which the customer-facing storefront is separated from the commerce backend. The frontend is responsible for how customers browse, discover products and move through the experience. The backend is responsible for the commerce operations behind that experience: product data, pricing, baskets, orders, customers, promotions, fulfilment and the interfaces that connect other systems.
In a conventional ecommerce platform, these layers are closely coupled. The platform provides a theme system, a storefront renderer, an admin, a commerce model and a set of extension points. That arrangement can be efficient because it gives the merchant a defined way of working. In a headless arrangement, the frontend talks to the backend through APIs instead. The presentation layer can therefore be changed without replacing the commerce core, and the commerce core can change without assuming that the customer experience must be rebuilt in the same way.
The practical point is not that every layer has to be custom. It is that the boundaries become visible. A product page can request product and inventory data from a commerce service, editorial content from a CMS, search results from a search service, and payment options through the approved checkout path. Each connection has an owner, a contract and a failure mode. That can give an established merchant useful control. It also means someone has to understand and operate those connections.
Headless is therefore a design choice, not a status symbol. It earns its complexity when the business needs greater freedom over the storefront, the data model, integrations, payments, compliance controls or operating workflow than a coupled platform can reasonably provide. If the existing platform still supports the commercial model, a conventional build can be faster to change and easier to run.
COMPOSABLE
A system assembled around explicit service boundaries.
Commerce, content, search, payments, tax, fulfilment and other capabilities can be selected independently where that choice earns its operating cost.
MACH
A set of architectural principles, not a compulsory shopping list.
Microservices, API-first, cloud-native SaaS and headless are useful ideas when they serve the merchant. They are not a reason to fragment a working operation.
02
HOW THE MODELS DIFFER
TRADITIONAL / HEADLESS / COMPOSABLEThe useful comparison is not “old versus new”. It is a comparison of where decisions sit, who owns them and how much coordination a change requires. A traditional platform packages many decisions together. A headless architecture separates the customer-facing application from the commerce backend. A composable architecture makes more of the service boundaries deliberate. Each can be the right answer for a particular merchant.
The table below is a decision aid, not a maturity ladder. Moving right creates more choice and more responsibility at the same time. The correct model is the least complex one that lets the business own the constraints that actually matter.
| Decision area | Traditional platform | Headless commerce | Composable commerce |
|---|---|---|---|
| Storefront delivery | Platform theme renders the customer experience inside a prescribed system. | A separate frontend consumes commerce APIs and controls presentation. | A frontend is one service among deliberate choices for commerce, content, search, payments and operations. |
| Commerce backend | Usually bundled with the platform and its native conventions. | Can remain on a platform or move to a dedicated commerce engine. | Chosen for the business model, with clear service boundaries and ownership. |
| Change surface | Most changes stay within theme, apps and platform configuration. | Frontend and backend can change independently through documented interfaces. | Each capability can evolve independently, but dependencies must be governed. |
| Content | Often coupled to templates and platform editorial models. | Can be served through a CMS or platform content layer to the frontend. | Content is selected and integrated as an explicit part of the architecture. |
| Search | Usually native or app-led, with platform-defined extension points. | Can be provided by the platform or a specialised service. | Search, indexing and merchandising are deliberate services with operational ownership. |
| Checkout | Follows the platform checkout model and approved extension points. | Depends on the commerce backend and provider constraints. | The payment, eligibility and checkout path is designed around the merchant and provider approvals. |
| Data model | Platform object model is the primary constraint and source of convention. | A frontend can model presentation separately from backend data. | Data ownership, transformations and contracts are explicit across services. |
| Integrations | Apps and native connectors are often the starting point. | APIs can connect the frontend and backend to specialist systems. | Integration boundaries, failure states and change ownership are planned as part of the product. |
| Performance work | Bounded by the theme, app stack and platform delivery model. | Frontend delivery can be tailored, but needs engineering discipline. | Performance is shared across services, observability and release controls. |
| Security and updates | Platform handles much of the underlying infrastructure and patching. | Responsibility is divided between vendors and the operating team. | The merchant needs an explicit security, vendor and release ownership model. |
| Merchandising operations | Usually follow the platform admin model and available apps. | The frontend can be flexible while operations still use the chosen backend. | Admin, catalogue and workflow tools are selected or extended around real operating needs. |
| Vendor dependency | Higher dependence on platform policy, roadmap and permitted integrations. | Dependency changes by backend choice, though the frontend is independently owned. | Dependency is distributed; lock-in can reduce, but service-management responsibility increases. |
| Release process | Platform deployments and theme changes can be comparatively contained. | Frontend, backend and integration changes require coordinated release practice. | Changes need versioned interfaces, checks, observability and clear rollback decisions. |
| Best fit | Standard commerce requirements with a team that values platform convention and speed of operation. | A real presentation, performance or experience constraint with adequate technical ownership. | Established merchants where multiple business-critical constraints justify a governed, modular operating model. |
| Poor fit | Only when the platform itself blocks a material commercial requirement. | When a custom frontend is being used as a vague status upgrade. | When the team wants more services without the budget, owners or discipline to operate their connections. |
03
WHAT HEADLESS CAN MAKE POSSIBLE
CONTROL / FLEXIBILITY / OPERATIONSThe benefits of headless commerce are often described as speed, flexibility and personalisation. Those can be real outcomes, but they are incomplete descriptions. The more durable benefit is the ability to make architectural decisions where the business actually needs them: which system owns which data, how customer experience changes are released, where an integration is allowed to shape a workflow, and how the store responds when policy or provider conditions change.
That control has value for established merchants with non-standard conditions. It has much less value when the proposed build is merely recreating standard platform features across more services. The sections below describe what an owned architecture can enable when the use case earns it.
FRONTEND FREEDOM
The storefront can be designed around the customer journey instead of being limited to a specific theme system. That can matter when product discovery, content, B2B flows, regional journeys or a distinctive buying experience are commercially important. It is not a reason to rebuild standard journeys simply because the technology allows it.
EXPLICIT BOUNDARIES
Separating presentation from commerce makes the interfaces visible: where pricing comes from, how inventory is exposed, which service owns search, and what happens when an integration fails. A visible boundary is useful only when someone owns it and the team can test the behaviour on both sides.
OWNERSHIP OPTIONS
An owned backend and custom frontend can reduce reliance on a single platform policy or product roadmap. That is relevant where payments, compliance, workflow or differentiation are material constraints. It does not eliminate vendors; it changes the merchant’s responsibility for choosing and managing them.
CHANGE WITHOUT A RESKIN
A separated architecture can let a team evolve presentation, integrations or operational tools without treating the whole store as a theme replacement. The benefit is controlled change, not constant change. Release discipline and a clear product backlog matter more than the novelty of the stack.
COMPLIANCE AS ARCHITECTURE
For restricted or regulated commerce, eligibility checks, payment continuity, auditability and policy changes may need to be designed into the operating model. A flexible architecture can support that work, but provider approval and merchant responsibility remain decisive.
A PRACTICAL OPERATING MODEL
Composable commerce can connect specialist tools where they genuinely improve a workflow. The objective is not a catalogue of vendors. It is a system that the merchant can explain, change and recover when a dependency or commercial rule changes.
04
WHEN HEADLESS COMMERCE IS WORTH IT
ESTABLISHED MERCHANTS / RIGHT FIT / WRONG FITHeadless commerce is not a revenue-band purchase. An established merchant can be a poor fit if the current platform already meets the business need; a smaller specialist can have a legitimate architecture case if payments, compliance or operational constraints are decisive. The common factor is not ambition. It is whether the existing system is constraining a material commercial outcome and whether the business can operate the greater freedom it is buying.
The right assessment starts with the constraint, not a preferred platform. It asks what has failed inside the current model, which journeys or workflows are affected, which data and integrations carry risk, and who will own change after the project. That conversation may lead to a custom build. It may also lead to better management, contained optimisation, or staying where the store is.
RIGHT FIT / THE CASE EARNS COMPLEXITY
01 / FIT SIGNAL
A platform decision has become commercial
The business has a named constraint around ownership, payment continuity, compliance, data, custom workflow, B2B logic or integrations. The problem has survived reasonable optimisation inside the current platform.
02 / FIT SIGNAL
The merchant is established enough to operate it
There are named decision-makers for commercial priorities, technical change and operational exceptions. The team does not need to be large, but it cannot treat the result as a self-running website.
03 / FIT SIGNAL
The customer journey needs genuine freedom
Product discovery, content, account behaviour, regional logic or buying flows have requirements that a template-plus-app approach cannot carry reliably or economically.
04 / FIT SIGNAL
Data and integrations are part of the product
The business recognises that customer, order, catalogue, content and operational data need a source of truth, mapped interfaces and validation, rather than a succession of point-to-point fixes.
05 / FIT SIGNAL
The build has a run model
The merchant has budget and appetite for releases, monitoring, provider changes, security, performance and continued prioritisation after the initial project.
WRONG FIT / KEEP THE DECISION SMALLER
01 / CAUTION
The current problem is a backlog
Slow changes, weak merchandising, stale content or a lack of senior ownership can often be addressed without replacing the platform. Start by identifying the operating constraint; the right answer may be better management of the current store.
02 / CAUTION
The brief is “make it headless”
Technology-led briefs can hide an unresolved commercial decision. If no customer, payment, workflow, data or ownership problem is named, headless is likely to add cost before it adds value.
03 / CAUTION
The team needs platform convention
A conventional platform can be valuable because it constrains choices, packages infrastructure and gives an operating team familiar controls. That is not a compromise when it suits the business.
04 / CAUTION
The budget ends at launch
A custom frontend and multiple services do not become cheaper to own after handover. Without a plan for maintenance, vendors, incidents and incremental change, the architecture creates a new dependency problem.
05 / CAUTION
A generic site is the entire requirement
If the catalogue, checkout, operational workflow and integrations are ordinary, a well-run platform implementation can be the more responsible choice. Complexity should be earned by the business case.
05
A COMPOSABLE STACK IS AN OPERATING SYSTEM
MEDUSA / FRONTEND / SERVICES / RUN MODELComposable commerce is sometimes presented as a menu of best-of-breed tools. That framing is incomplete. A useful stack is not defined by how many specialist services it contains. It is defined by whether the boundaries between those services reflect the merchant’s commercial model, whether data and decisions have clear owners, and whether the team can observe and change the system safely.
For a complex merchant, the architecture may include a Medusa commerce core and a custom frontend. It may also include specialist content, search, payment, tax, compliance or operational services where they solve an explicit requirement. The correct shape depends on the business. The durable requirement is a delivery model that connects build decisions to the people who will run the store.
01 / COMMERCE CORE
The engine that owns products, pricing, carts, orders, customers, promotions, fulfilment and the API contract to the rest of the system. Medusa is one option when open-source, self-hosted commerce and extension control are appropriate.
02 / CUSTOMER FRONTEND
The customer-facing application that handles browsing, content presentation, account journeys, basket and checkout hand-off. Its job is to serve the agreed experience, not to carry hidden business logic that operations cannot find.
03 / CONTENT AND SEARCH
Editorial content, product discovery, indexing and merchandising systems need their own ownership. The question is not whether every merchant needs a separate service; it is whether the selected tools meet the catalogue, publishing and search behaviours that matter.
04 / PAYMENTS AND COMPLIANCE
Payment providers, age or eligibility checks, tax, duty, consent and other controls are selected against the merchant, vertical and approval path. Architecture can make room for these requirements; it cannot substitute for provider acceptance or legal responsibility.
05 / OPERATIONS AND DELIVERY
Admin workflow, data quality, releases, monitoring, access, incident response and the prioritised backlog are part of the product. This layer decides whether a composed stack remains a useful system after the initial build.
BUILD / IMPLEMENTATION ROUTE
Choose the layer that needs a decision.
Use the Medusa page when the commerce-core ownership case is already clear. Use custom ecommerce development when the broader build requirement is clear but the stack still needs architecture. Use the migration route when the first decision is whether a change of platform is justified at all.
06
HEADLESS VS SHOPIFY: THE REAL TRADE-OFFS
SHOPIFY / CUSTOM FRONTEND / OWNED BACKEND“Headless versus Shopify” can mean several different decisions. A merchant may be asking whether to use a custom frontend on top of Shopify, whether Shopify remains appropriate as the commerce backend, whether a specific checkout or payment constraint can be resolved inside the platform, or whether the business needs an owned commerce core. These are related questions, but they should not be collapsed into one technology preference.
Shopify remains a strong choice when its conventions support the business and the operating team values a managed platform. A headless Shopify frontend can be useful when the storefront is the constraint. An independently owned stack becomes more relevant when the constraint reaches the backend, payments, data, integrations, compliance or the business’s ability to make and govern changes. The responsible route is to name the layer before prescribing the answer.
What Shopify can make easier
A hosted platform can give a merchant a defined admin, a conventional operating model, managed infrastructure and a broad ecosystem. That can reduce decisions and accelerate ordinary commerce work. Shopify can also be used headlessly, which may be appropriate where the storefront is the main constraint rather than the commerce model.
Where the trade-off changes
The decision changes when platform policy, checkout boundaries, payment acceptance, data ownership, bespoke workflows, integration limits or operational requirements become commercially material. A custom frontend alone does not resolve every one of those constraints. The merchant needs to identify which layer is actually limiting the business.
What headless adds
Headless can create more control over the customer experience and separate it from the backend. It also adds the need to operate a frontend codebase, APIs, deployments, observability and the contracts between systems. The build should make that responsibility clearer, not obscure it behind agency terminology.
When Medusa may be relevant
Medusa is relevant when an open-source, self-hosted commerce core and extensible module model meet the ownership case. It is not a default replacement for a hosted platform. Read the Medusa development page for the implementation and operating standard, not a platform sales script.
Considering Medusa?
Medusa development explains when an open-source, self-hosted commerce core earns the operating responsibility.
Considering a broader build?
Custom ecommerce development covers the discovery, architecture and build path for stores that do not fit the template.
07
HEADLESS COMMERCE FAQ
PAA / DECISION SUPPORT / NEXT STEPWhat does headless commerce mean?
Headless commerce separates the customer-facing storefront from the commerce engine behind it. The frontend presents products, content and checkout journeys; the backend manages product, pricing, basket, order, customer and integration logic through APIs. The two layers can be changed independently, provided the operating model and interfaces remain clear.
Is a headless CMS the same as headless commerce?
No. A headless CMS separates editorial content from its presentation layer. Headless commerce applies the same separation to commerce functions such as catalogue, cart, checkout, pricing, customer accounts and orders. A merchant can use a headless CMS, a headless commerce backend, both, or neither.
What is the difference between headless and composable commerce?
Headless describes the separation of frontend and backend. Composable commerce describes an architecture assembled from independently chosen services with explicit boundaries, such as commerce, search, content, payments, tax or fulfilment. A headless build can be relatively simple; a composable build adds deliberate service choices and the responsibility to operate their connections.
Is Shopify headless commerce?
Shopify can be used in a headless arrangement by connecting a custom frontend to Shopify commerce APIs. That does not automatically make it the right architecture. The merchant still needs to assess which parts of the commerce model, checkout, data, integrations and operating controls remain owned by Shopify and which constraints the custom frontend actually solves.
Does every ecommerce store need to go headless?
No. A conventional platform and theme remain a sensible answer when the commercial requirement is standard, the team benefits from platform conventions, and the store does not need bespoke control over architecture, data, payments, compliance or operational workflows. Headless adds capability and responsibility together.
Do I need a developer to run a headless commerce store?
A headless store needs named technical ownership, whether that sits within an internal team, a retained partner or a documented support arrangement. Day-to-day merchandising should not require a developer for every change, but releases, integrations, performance, security, incidents and structural changes need an accountable operating path.
Is headless commerce the same as MACH architecture?
No. MACH is a set of architectural principles commonly expanded as microservices, API-first, cloud-native SaaS and headless. Headless can be one part of a MACH-style architecture without requiring every service to be independently selected or operated. The useful question is whether each extra boundary earns its operational cost.
What does headless commerce typically cost?
Cost depends on the existing stack, data condition, catalogue and checkout complexity, integrations, content model, compliance requirements and expected operating model. Hollow Point does not use a generic headless price because a credible scope starts with the constraint and the risk. First BUILD projects are typically £30k–£50k, subject to scope and complexity.
What are the risks of migrating to headless commerce?
The main risks are treating a replatform as a frontend project, under-mapping data and integrations, losing search or route parity, selecting more services than the team can operate, and releasing without clear acceptance checks or rollback conditions. A migration assessment makes those dependencies visible before a cutover window is committed.
Is my business ready for headless commerce?
Readiness is less about a revenue threshold than a real constraint and the ability to operate the result. Established merchants are better candidates when platform ownership, complex catalogue logic, payments, compliance, integration or workflow needs are shaping commercial outcomes, and when the business can name owners for the stack after launch.
How does AI integrate with headless commerce?
A separated architecture can make it easier to connect defined services to a commerce workflow, but AI is not an architectural reason on its own. The useful question is which decision, workflow or operating task needs support, what data it can safely use, and who remains accountable for the result. The integration should have a clear boundary and fallback path.
What team roles are required for composable commerce?
The exact roles vary, but someone must own product and commercial priorities, technical architecture and releases, catalogue and content operations, integrations, and incident or change decisions. A small team can cover multiple responsibilities. What matters is that ownership is explicit rather than assumed to sit inside a platform or agency handover.