Headless commerce: when the freedom is worth it

Headless commerce is the same idea as a headless CMS, pointed at your store instead of your content. You take the shopper-facing part of your shop, the storefront, and separate it from the commerce engine that handles catalogue, cart, checkout, and orders. The two then talk through an API. The engine does the commerce; a front end you build does the presentation.

The plain version: the part customers see is unbolted from the part that runs the transactions, so you can change either one without disturbing the other.

That separation buys you real freedom, and it hands you real work, and the whole decision is about whether the first outweighs the second for your particular shop. I’ll try to give you an honest way to tell, rather than the usual pitch where freedom is free.

What headless means here

A traditional commerce platform ships the storefront and the engine as one thing. The templates that render your product pages are part of the same system that processes the orders. Change the look, and you’re working inside the platform’s templating, with its constraints, in its way. This is fast to launch and easy for a small team, and it’s exactly what most shops should start with.

Headless splits those apart. The engine keeps doing catalogue, pricing, inventory, cart, checkout, orders, and exposes all of it through an API. The storefront becomes a separate application your developers build, which requests product data and pushes cart actions through that API. When someone adds to basket on your custom front end, that action travels to the engine; when they check out, the engine handles it. The customer sees your front end and never knows there’s a separate engine behind it.

The “head” is the storefront, the presentation. Cut it off from the body, the engine, and you’ve gone headless. Same anatomy as a headless CMS, applied to selling.

What it buys you

Four things, and they matter to different shops in very different amounts.

Total control of the experience. Because the front end is yours to build, you’re not confined to what the platform’s templates allow. You can create exactly the shopping experience you want, at whatever level of polish and distinctiveness you can build. For a brand whose experience is its edge, this is the whole point.

Speed, when it’s built for it. A purpose-built front end can be lean and fast, and in commerce speed is money, since slow pages lose sales measurably. A well-built headless storefront often outperforms the templated site it replaced. Note the “well-built,” though; the architecture makes speed possible rather than guaranteed.

Many front ends, one engine. Because the engine serves everything through an API, you can put several front ends on top: a website, a mobile app, an in-store screen, a social storefront, all pulling from one catalogue and one cart. If you genuinely sell across surfaces, this is a large advantage. If you sell on one website, it’s a benefit you won’t use.

Freedom to redesign without re-platforming. Your storefront and your engine evolve independently, so a redesign is a front-end project rather than a terrifying migration of everything. You can also change the engine later without rebuilding the customer experience. That independence is worth a lot to anyone who expects to keep changing.

Notice that two of those four only pay off under specific conditions, multiple channels and a brand that competes on experience. That’s the pattern with headless: the benefits are real but conditional.

What it costs

The honest column, because a storefront doesn’t build or maintain itself.

You need developers, and you keep needing them. In a traditional platform a marketer can often build a page alone. Headless removes the built-in presentation layer, so the storefront has to be built and maintained by people who write code. That’s not a one-off; the front end is software you own for as long as you run it. This is the single biggest cost and the most common reason headless disappoints teams who were sold speed.

Launch takes longer. A templated platform gets you selling quickly. A headless build starts with building the storefront, which takes time before the first order. You’re trading a slower start for more control and faster change later, which is a good trade only if you’ll actually use the control and the change.

More to maintain and monitor. Two systems and an API between them is more surface area than one integrated platform. It’s manageable, and it’s more than nothing, and someone has to own it.

Some conveniences you have to rebuild. Previewing a page, certain merchandising tools, and other niceties that came free in the templated platform may need building or wiring up in a headless setup. Good tooling reduces this; it rarely eliminates it. Worth checking specifically rather than assuming.

None of this makes headless wrong. It makes it a commitment with a clear prerequisite: developers you can sustain. With them, the freedom is real. Without them, you’ve bought complexity you can’t use.

The same shop, both ways

An example makes the trade concrete, so here’s one ordinary situation handled on a templated platform and on a headless one.

You want to launch a campaign landing page for a seasonal collection: distinctive layout, video header, a curated set of products, some editorial storytelling between them, and add-to-basket working throughout.

On a templated platform, you work within what the templates allow. You can usually get something decent, but the distinctive layout fights the theme, the video header needs a plugin or a workaround, and the editorial-between-products pattern isn’t how the platform likes to arrange things. You end up with a page that’s fine, delivered quickly, that looks recognisably like your platform rather than uniquely like your brand. For a lot of shops that’s a perfectly good outcome, and the speed is worth more than the distinctiveness.

On a headless setup, your developers build exactly the page you designed, because the front end is theirs to build. The video header, the custom layout, the editorial flow, all just code. Add-to-basket calls the engine’s API in the background, so the commerce works while the presentation is entirely your own. The page looks like nothing anyone else has, and it took developer time to make, and you’ll maintain it as code.

That’s the trade in one page. The templated version is faster and more constrained; the headless version is slower and unconstrained. Neither is better in the abstract. The question is whether a page that looks uniquely yours is worth developer time to you, and that depends entirely on whether your brand experience is something customers actually choose you for. A fashion label competing on feel answers yes. A parts distributor competing on range and price answers no, and should.

The mistake is answering yes because unconstrained sounds better than constrained. Constraints you don’t feel are free, and the freedom you don’t use is expensive.

Two things people get wrong

Worth clearing up two misconceptions, because both lead to bad decisions.

The first is that headless is automatically faster. It can be faster, and it is not faster by default. A headless storefront built carelessly can be slower than a decent templated site, because performance comes from how the front end is built, not from the architecture itself. Headless gives your team the ability to build something very fast and the freedom to build something slow. Which you get depends on the team, not the label. Anyone promising speed as a guaranteed feature of headless is overselling.

The second is that headless and replatforming your engine are the same project. They are not, and conflating them causes needless fear. You can go headless while keeping your existing commerce engine, if that engine can expose its functions through an API. In that case you build a new storefront and leave the engine that already handles your orders in place. Plenty of shops do exactly this as a first step: new front end, familiar engine, one change at a time. Ripping out the engine as well is a separate, larger decision you can make later or never. Treating “go headless” as “replace everything” turns a manageable move into a daunting one and talks teams out of something that would have suited them.

Both misconceptions push in the same unhelpful direction, making headless sound either magically better or terrifyingly total. It’s neither. It’s a specific, boundaried choice about separating presentation from commerce, with a clear prerequisite and a clear payoff when the conditions fit.

How to tell

A short, honest test. The more of these that are true, the more headless makes sense.

You sell on more than one surface, or you will soon. Website plus app, plus connected screens, plus social. If the honest answer is one website with no real plans beyond it, the strongest argument for headless doesn’t apply to you.

Your experience is a competitive advantage. If shoppers choose you partly because your storefront is unusually good, the control headless gives is worth paying for. If your experience is fine and your competition is on price or range, less so.

You have developers, or will genuinely hire them. Not “the agency could probably manage.” A team that owns the front end. This is the deciding factor, exactly as it is for every headless and composable decision.

You expect to keep changing. Frequent redesigns, new channels, evolving requirements. Headless rewards change and charges you upfront for it. If your shop is stable and works, that upfront cost buys little.

You’re hitting the walls of your current platform. If your templated platform genuinely can’t do what you need and you’ve felt that pain, headless removes the ceiling. If you’re just curious about a modern approach, curiosity is a poor reason to take on a storefront.

If most of these are yes, headless likely pays off. If most are no, a good traditional platform will serve you better and cost far less to run, and choosing it is sound judgement rather than caution.

A readiness worksheet

The decision is really about channels, differentiation, and developer capacity, not about which architecture sounds current.

We’ve put it into a short readiness worksheet: the five tests above scored, a two-column cost comparison against staying on a templated platform including the ongoing front-end maintenance line, and a section for listing the conveniences you’d need to rebuild so none of them surprise you later. Fill it in with your technical lead present. If nobody in the room will own the storefront, that answers the question before you score anything.

The relationships

Headless commerce sits inside the same family of terms we’ve covered, so here’s exactly where it fits, since the words get used loosely.

Headless is specifically the split between storefront and engine. It’s one architectural choice, and you can do it on its own, keeping an otherwise traditional engine and just building a custom front end.

Composable commerce is the broader strategy of assembling your whole store from best-of-breed pieces, of which a headless storefront is usually one. You can be headless without being fully composable, but you can’t really be composable without being headless somewhere.

MACH is the set of technical principles, microservices, API-first, cloud-native, headless, that a rigorous composable build follows. Headless is literally the H.

So the nesting is: headless is one piece, composable is the strategy that piece serves, MACH is the discipline for building it well. If you only remember one thing, remember that headless is a narrow, specific choice about separating presentation from commerce, and everything else is built around it. Whether it’s right for you comes down to the five tests, not the vocabulary.

The stuff worth remembering

Headless commerce separates the storefront from the commerce engine, connecting them by API. The engine runs transactions; a front end you build handles presentation.
It buys total control of the experience, potential speed, multiple front ends on one engine, and freedom to redesign without re-platforming.
Two of those four only pay off with multiple channels or a brand that competes on experience. The benefits are real but conditional.
It costs developers you keep needing, a longer launch, more to maintain, and some conveniences you rebuild. The developer requirement is the deciding one.
Reach for it if you sell across surfaces, your experience is an advantage, you have developers, you change often, and your current platform is holding you back.
If most of those are no, a traditional platform will serve you better for far less. That’s a sound choice, not a timid one.
Headless is one piece, composable is the strategy, MACH is the discipline. Don’t let the words blur the actual decision.

Not sure whether headless is worth it for you?

Headless commerce makes more sense next to composable commerce, a clear comparison of the two, and the MACH architecture underneath.

The useful version of this conversation starts with where you sell, what you compete on, and who would own the storefront. If you’d like a second opinion on whether the freedom earns its cost for your shop, or whether a strong traditional platform would serve you better, get in touch and we’ll work through it with you.