Headless commerce: what it is and who actually needs it

Headless commerce means the part of your store customers see is built and hosted separately from the platform that holds your products, prices, stock and orders. The two talk to each other through an API. You gain complete freedom over the front end. You pay for it with a second system to build, host and maintain.

Most retailers do not need it. A well-built theme on Shopify, or a modern front end on Adobe Commerce, is fast, flexible enough and far cheaper to run. Headless earns its place in a small number of specific situations, and we set those out below.

The short version

• Headless separates the storefront (the "head") from the commerce platform behind it, joined by an API.
• It buys design and technical freedom, and it costs a larger build, a permanent developer dependency and features you used to get for free.
• Speed alone is not a reason: a good theme can be very fast, and a poor headless build can be slow.
• Shopify offers Hydrogen and the Storefront API, Adobe offers a storefront built on Edge Delivery Services, and BigCommerce offers Catalyst.
• If your marketing team values making changes without a developer, headless usually takes that away unless you pay to build it back.
• Test the need honestly: name the thing a theme cannot do, and put a value on it.

What does headless commerce mean?

On a conventional store, one system does everything. Shopify, for example, stores your catalogue and also produces the pages through a theme. Change the theme and the pages change.

In a headless build, the platform keeps doing the commerce: products, pricing, stock, customers, orders, payments. But the pages are produced by a separate application, usually written in a JavaScript framework such as React, which asks the platform for data through an API and draws the page itself. Content often comes from a third system, a headless content management system.

You will also hear "composable commerce". That is the same idea taken further: search from one supplier, content from another, checkout from a third, all assembled by your developers.

What you gain and what it costs

The gains

• Freedom over the experience. Unusual product builders, rich editorial layouts, app-like interactions.
• One back end, several front ends. The same catalogue can serve a website, a mobile app, in-store screens or a trade portal.
• Content and commerce from different systems. Useful when a large editorial team already works in a content platform they will not give up.
• Control over performance. A skilled team can tune every request. That is a possibility, not a guarantee.

The costs

• Two things to build. You are commissioning a custom web application on top of a store.
• Apps stop being plug and play. Reviews, search, loyalty, personalisation and many others are designed to drop into a theme. In a headless build each one has to be wired in through its API, if it has one.
• The theme editor goes. Drag-and-drop sections, scheduled changes and previews have to be recreated in a CMS or done by developers.
• More to monitor. Tracking, consent, SEO basics such as redirects, sitemaps and structured data, and accessibility are your team's job, not the platform's.
• A permanent dependency. Framework versions move on. Someone has to keep the front end current, and it needs to be someone you can still hire in three years.

The running cost is the part buyers underestimate. Our guide to what an e-commerce platform really costs covers how to total it over several years.

What the main platforms offer

Shopify: Hydrogen, Oxygen and the Storefront API

The Storefront API is how any custom front end reads products and collections from Shopify and manages a cart. You can use it from whatever framework your developers prefer.

Hydrogen is Shopify's own starting point: a set of components and tools built on React Router, an open-source React framework. Oxygen is Shopify's hosting for Hydrogen storefronts, and Shopify's documentation says it is available at no extra charge on paid plans. So the hosting is not the expense. The developers are.

In practice the checkout normally stays on Shopify's own hosted checkout, which is what you want: it is the part Shopify has optimised hardest. Hydrogen is a credible choice for brands on Shopify Plus with an in-house or retained development team. For everyone else, a modern Shopify theme covers more ground than it did a few years ago.

Adobe Commerce

Adobe Commerce (and Magento Open Source) has supported separate front ends through its GraphQL API for years. Adobe's current direction is the Commerce Storefront powered by Edge Delivery Services, with ready-made "drop-in" components for cart, checkout, product pages and accounts. Adobe's documentation says those drop-ins are included with some Adobe Commerce products and need an additional licence with others, so confirm what your contract covers before you plan around them.

PWA Studio, Adobe's earlier React toolkit, is still in use on existing sites. And there is a middle path many Magento retailers take: a lighter, faster conventional theme such as Hyvä, which fixes the speed complaint without going headless at all. We compare the two ecosystems in Shopify vs Magento.

BigCommerce and others

BigCommerce has long sold itself on being API-friendly, and its Catalyst storefront is a Next.js starting point with a hosted checkout. Beyond the mainstream platforms sit API-only commerce engines aimed at large enterprises with big engineering teams. If you are reading this guide to find out what headless is, those are not for you yet.

Who actually needs headless?

We'd consider it seriously when most of these are true:

• You can name a specific customer experience that a theme cannot deliver, and you have evidence it is worth real revenue.
• You have, or will fund, a development team that owns the front end for years, not just for the build.
• You need the same commerce back end to feed more than a website: an app, kiosks, several brand sites with different front ends.
• Content is central to how you sell and your editors need a proper content platform.
• Your online revenue is large enough that a small conversion gain covers a much larger build and its upkeep.

When headless is the wrong choice

• "We want a faster site." Start by fixing the theme: fewer apps, lighter images, less third-party script. That is weeks of work, not months.
• "Our agency recommended it." Ask what it will let you do that a theme will not, and what it will cost each year after launch. A good agency answers both without hesitating.
• "We want to be future-proof." A custom front end is the part most likely to need rebuilding. The platform's own theme system is maintained for you.
• Your team is small. If one or two people run trading, content and marketing, the loss of the theme editor will cost more than headless gains.
• You are replatforming at the same time. Changing platform and architecture together doubles the risk. See our guide to replatforming.

The outcome to avoid is going headless, finding that every landing page and promotion now needs a developer, and moving back to a theme. It is an expensive round trip.

A middle path

You do not have to choose all or nothing. Options that give some of the benefit at a fraction of the cost:

• A custom-built theme, designed and coded for you, on the platform's standard system.
• Custom sections or small embedded applications for the one or two interactive features you need (a configurator, a quiz, a bundle builder), inside an otherwise normal theme.
• A headless content system feeding a standard storefront, where the content team's needs are the real driver.
• A second, separate front end for the special case (an app or a trade portal) while the main store stays on a theme.

How we'd approach it

We'd start by asking what you are trying to fix. If it is speed, we measure the current site and find where the time goes. If it is flexibility, we list the things your team could not do in the last six months and check whether a theme rebuild would have allowed them. In most cases the answer is a better theme, built properly by our development team on Shopify or Adobe Commerce, followed by a programme of testing.

Where headless is justified, we'd scope the front end, the content system and every third-party tool's integration as separate lines, with a running cost for each, so you see the five-year figure before you commit.

Questions we get asked

Want a second opinion on your own setup? Thirty minutes with a strategist, and you leave with a clear next step.