Insights Architecture
Headless commerce: when it’s worth it, and when it isn’t
Separating the storefront from the commerce platform can solve real problems. It also creates a second system to build, host and maintain. Here is how to tell whether the trade is worth making.
Headless commerce is often presented as the natural next step for any growing store. It isn’t. For some businesses it removes a genuine constraint; for many it replaces a theme that could have been optimised with a separate application that needs its own developers, hosting and release process. This article sets out the difference.
What headless means
In a conventional ecommerce platform, the storefront – the pages customers see – is rendered by the platform itself using its theme or template system. In a headless setup, the storefront is a separate application. It fetches products, prices, stock and cart data from the commerce platform through APIs and renders the pages itself.
The commerce platform still does the commerce: catalogue, pricing, inventory, orders and, very often, checkout. Headless changes who draws the pages, not who takes the money.
Composable commerce goes a step further, assembling the whole stack from separate services – search from one provider, content from another, promotions or order management from others – connected through APIs. Every composable setup is headless; most headless setups are not fully composable.
What it gives you
- Freedom from the theme system. The front end can be built in any framework, laid out however the experience requires, and combine commerce data with content from elsewhere.
- Several front ends, one back end. A website, a mobile app, in-store screens and other channels can share one catalogue, one set of prices and one order flow.
- Control over performance. Rendering, caching and what JavaScript reaches the browser are under your control rather than the theme’s and the apps’.
- Independent releases. Front-end changes can ship without touching the commerce platform, and the other way round.
What it costs you
The costs are less about the initial build than about everything the platform’s own storefront was quietly doing for you.
- A second application to run. The front end needs hosting, monitoring, security updates and framework upgrades for as long as it exists.
- Features you rebuild. Search and filtering, account pages, wish lists, reviews and anything an app added to the theme may need building again, because many apps only work with the platform’s own storefront.
- Content editing. Merchandisers still need to change pages and see a preview before publishing. That usually means a separate content management system and integration work to make previews reliable.
- Search visibility. Server-side rendering, redirects, canonical tags, structured data and sitemaps become your code’s responsibility rather than the platform’s defaults.
- Analytics and tracking. Events that the platform or its apps sent automatically have to be implemented and tested again.
- A team that stays. A headless storefront without developers who understand it becomes the next rescue project.
When headless makes sense
- You genuinely serve several front ends from one commerce back end.
- The experience depends on combining commerce with rich content or interactive tools in ways the theme system can’t support.
- You have measured the storefront’s performance, optimised the theme and apps properly, and it still can’t meet your requirements.
- You have an in-house or retained front-end team for the long term.
When it usually doesn’t
- The motive is a slow site that has never been properly optimised. Removing unused apps, fixing images and scripts and tuning the theme costs far less.
- The store relies on apps that inject features into the theme.
- Speed to market matters more than front-end freedom.
- Nobody will own the front end once the project team has gone.
Platform options
Most established platforms can be used headless. The differences are in how complete the APIs are and what remains on the platform.
- Shopify provides the Storefront API for headless front ends and its own React-based framework, Hydrogen, which can be hosted on Shopify’s Oxygen. Checkout remains Shopify’s.
- BigCommerce offers a GraphQL Storefront API intended for headless storefronts.
- Magento and Adobe Commerce expose a GraphQL API covering catalogue, cart and customer operations.
- WooCommerce offers its REST API and the Store API used by its own cart and checkout blocks, with WordPress continuing to manage products and content.
- API-first platforms such as commercetools are designed to be used this way from the start, typically as part of a composable stack.
The right choice depends far more on your catalogue, pricing, integrations and team than on the front-end framework.
Questions to answer before committing
- Which specific problem does headless solve that optimising the current storefront wouldn’t?
- What do the theme and apps do today that would have to be rebuilt, and who has listed it?
- How will merchandisers edit and preview content?
- Who will maintain, host and upgrade the front end in two years’ time?
- How will rendering, redirects and structured data be handled so search visibility isn’t lost?
If the answers are clear and the first one is convincing, headless may well be right. If not, the better investment is usually in the platform you have. A technical review can tell you which, before either route is funded.