What is headless commerce?

What is headless commerce?

Headless commerce separates the storefront a shopper sees from the commerce engine behind it.

The engine keeps doing the commerce work — catalogue, cart, checkout, orders — but stops rendering pages. The front end is built separately and talks to it through APIs. The point is control over presentation: custom experiences, multiple touchpoints, a design not constrained by the platform's templating.

It is an architectural choice about where the presentation layer lives, not a product category you buy. That distinction matters more than it sounds, because it is why the next question has a surprising answer.

Is headless commerce the same as composable commerce?

No, though they travel together — and conflating them is what makes buyers overestimate what headless requires.

Composable architectures commonly use a headless front end, but headless does not require a composable stack — and that is the case most buyers here are actually in. Only a handful of the interviews mentioning headless mention composable at all.

One footnote worth having: MACH, the industry's umbrella term for the composable approach, is almost entirely absent from these interviews. Buyers say “headless” constantly and effectively never say MACH. If you are reading vendor material organised around that acronym, you are reading a vocabulary that barely appears in these buyer interviews.

What platforms do buyers run headless commerce on?

Shopify. Among the interviews mentioning headless, it appears several times more often than commercetools — the platform most associated with going composable.

This is the finding that most contradicts how the topic is usually presented. Headless is written about as an enterprise-composable decision; buyers describe it as something they do on top of a mainstream platform.

The pattern in their own words is consistent. One describes using Shopify as the backend e-commerce engine supporting a customized frontend setup, which is part of a headless architecture. Another, running a headless site, says they rely on Shopify for its flexibility and integration. A third combines custom code and Shopify's capabilities as part of our headless e-commerce approach.

The logic holds together: keep the catalogue, the checkout and the app ecosystem that works, and take control only of the layer you actually need to control. Going composable is a much larger commitment, and most buyers describing headless have not made it.

One buyer, asked about their setup, answered: I'm not entirely sure whether it's a headless setup or integrated differently. A useful reminder that buyers do not always classify their own architecture as neatly as vendor categories do.

What does headless commerce cost?

The cost buyers emphasize is engineering — and it arrives in places the architecture diagram does not show.

The second is the one worth pausing on, because it is the least visible going in. Off-the-shelf convenience and front-end control trade against each other, and the trade is not obvious until something you assumed you could install turns out to need building.

Do buyers regret going headless?

A few describe moving back. It is a small number of accounts, not a broad reversal — but both cite the same problem: cost and complexity relative to the value they needed.

One buyer is actively moving away from headless commerce due to its complexity and cost, shifting toward more off-the-shelf solutions, like native Shopify tools, with the aim of eliminating overly custom setups.

Another, running commercetools, rates it three out of ten and is blunt about why: it's extremely expensive and not well suited to our current company size. We find the headless commerce approach not entirely necessary for us. The costs and development demands outweigh the benefits we initially anticipated.

That second account comes from a composable build, so its cost cannot be attributed to headless alone — though the buyer explicitly includes the headless approach in what they now consider unnecessary.

Two accounts, and we are not going to call it a trend. But note what neither says: neither describes headless failing technically. Both describe it working and not being worth what it costs them — a different problem, and one worth testing before you build rather than discovering after.

How do buyers rate the platforms?

Average buyer rating (1–10) for the commerce platforms buyers name around headless builds.

Platform	Avg rating	Where it sits in this picture
Shopify Plus	8.2	The larger-program tier, and the highest-rated platform here.
Shopify	8.1	The platform buyers most often run headless on — as the engine underneath a custom front end, not as a composable component.
BigCommerce	6.8	Named as a mainstream platform with headless capability rather than a composable choice.
Salesforce Commerce Cloud	6.6	An enterprise incumbent that appears repeatedly in replatforming conversations, headless or otherwise.
commercetools	6.5	The composable-native option. One buyer gives it the sharpest cost complaint on this page — chosen for flexibility, then questioned on whether the flexibility was needed.
SAP Hybris	5.3	The lowest-rated of this set. One buyer here describes consolidating multiple commerce platforms onto it while adding headless on top.
VTEX	not rated	Named for offering headless capability for future adaptability rather than as a live headless build. Too few buyers to publish a rating.

Do you need headless commerce?

The first question to answer is what the front-end control is actually for.

Our reading, rather than a claim buyers make: the stronger the requirement for a storefront the native platform cannot produce — several distinct touchpoints, a design its templating cannot express, an experience that is the product — the easier the engineering overhead is to justify. Where the honest answer is that the site could have been built on the platform's templates, the buyer accounts above describe paying an engineering cost indefinitely for something they did not need.

Three checks are more useful than the architecture debate, and these are our recommendation rather than a practice buyers describe. What can't the native storefront do? If you cannot name it concretely, that is the answer. What are you giving up? List the apps and off-the-shelf conveniences you currently rely on, and ask which survive a custom front end — that is the cost buyers report being surprised by. Who maintains it in two years? The build is a project; the front end is a permanent responsibility.

And separate the two decisions. Going headless does not require going composable, and most buyers here have done the first without the second. If you are weighing the larger platform question, why brands replatform and what buyers wish they had known first cover it directly.

Common questions