Re:platform Podcast: The Pros, Cons & Challenges of Headless Commerce

We joined James Gurd and Paul Rogers on the Re:platform podcast to talk about headless commerce — not the pitch, the practice. What it buys you, what it costs you, and the bits that only show up once you are living with it.

Listen to the episode — the show now lives at Inside Commerce.

PWA and SPA are not the same argument

The two get used interchangeably and they should not be. A progressive web app is about how the site behaves on a device — installability, offline tolerance, app-like navigation. A single-page application is an architectural decision about where rendering happens. You can have one without the other, and conflating them is how projects end up buying complexity they never wanted.

Worth getting straight before anyone signs anything, because the two carry very different bills.

What a SPA actually costs your team

The trade nobody puts on the slide: you are moving work from the platform to your own engineers. State, routing, caching and error handling all become yours to own. That is fine if you have the team for it, and a slow-motion problem if you do not.

It changes the internal shape of a project too. Your IT team inherits a front end with its own release cycle, its own dependencies and its own failure modes — separate from the commerce platform behind it. That is the point of going headless, but it is a commitment rather than a free upgrade.

Measurement gets harder before it gets better

Decoupled front ends break assumptions your analytics were quietly relying on. Page views stop meaning what they meant. Third-party tags that expected a full page load need rethinking. Core Web Vitals move in ways that surprise people — sometimes for the better, sometimes not, and rarely uniformly across templates.

None of that is a reason to avoid headless. It is a reason to plan the measurement work as part of the build rather than discovering it in week three of live trading.

The launch is not the finish line

The projects that pay off are the ones set up to keep improving after go-live. That means being able to ship a change to one template without a full release, and having the numbers to know whether it worked.

It is the same argument we make about replatforming generally: the build is the start of the relationship, not the end of it. We have written more about designing for constant growth if that is the part you care about.

Why we built our own CMS

The question James put to us directly: with plenty of headless CMS products on the market, why build one?

The short version is control over the authoring experience. Off-the-shelf tools were either too general — powerful, but leaving merchandisers to assemble pages from primitives — or too rigid to fit how our clients actually work. Building it meant the editing model could match the commerce model rather than sitting awkwardly beside it.

That answer has a shelf life, and the market has moved since. It was the right call for the builds we were doing at the time.

Where this has been put to work

The headless builds behind the conversation are real ones: Agent Provocateur, Oliver Bonas, Vashi and Topps Tiles. Different catalogues, different buyers, and in Topps Tiles' case both trade and retail on the same platform.

Headless earned its place on those projects. It would not have on all of them.

Still true, five years on

The specifics have aged — frameworks have turned over, Adobe has shipped a great deal since, and some of what needed building yourself now comes in the box. The judgement has not: headless is an architecture decision with a running cost, and it is worth it when you have something specific you cannot do otherwise.

If you are weighing it up, let's talk. We will tell you if the answer is no.