What Is Headless Commerce? A Plain-English Guide for UK and Australian Retailers

TL;DR: Headless commerce splits what shoppers see (the storefront) from what runs the shop (catalogue, cart, orders, payments), and connects the two through APIs. You gain freedom over the front end, and you can serve websites, apps and in-store screens from one back end. You also take on more engineering, more moving parts and a higher running cost than a standard theme. For many UK and Australian retailers a well-tuned theme is still the right answer. This guide explains the idea in plain English, shows what changes in practice, and gives you a checklist for deciding.

What does "headless" actually mean?

Picture a conventional online shop as a single building. The shop window, the till, the stockroom and the accounts office all sit under one roof, built by one supplier, and the window display can only be rearranged in the ways the building allows.

Headless commerce takes the shop window (the "head") off the building. The stockroom, till and accounts carry on running, but now they expose a set of doors, called APIs, that any display can plug into. The display might be a website built in a modern JavaScript framework, a mobile app, a kiosk in a store, or a voice assistant.

The definitions from the big vendors agree on the core point. Shopify describes headless commerce as something that "separates your storefront's frontend from its backend": you build the frontend, and the platform's APIs handle commerce underneath. Mastercard's technical guide puts it the same way: the backend runs on a server and exposes its functions through APIs, so any user interface can connect to it.

That is the whole idea. Everything else in this article is about what follows from it.

Traditional, headless and composable: three terms, one spectrum

These words get used loosely, and sales pages often blur them. Here is how we use them.

Traditional (monolithic) commerce. One platform provides the storefront, the checkout, the admin area and the data model. You customise through themes, plugins and apps. It is quick to launch and easy to reason about, because there is one vendor and one place to look when something breaks.

Headless commerce. The storefront is separate. The commerce engine (products, prices, baskets, orders) stays in a platform or a custom service, and the storefront talks to it through APIs. Your team, or your agency, owns the front end.

Composable commerce. This goes a step further. Not only the front end but other capabilities, such as search, content management, promotions, loyalty or reviews, are picked as separate services and stitched together. The industry shorthand is MACH: microservices, API-first, cloud-native and headless. A fully composable build gives you the most choice and the most integration work.

Think of it as a dial, not a switch. Many retailers sit in the middle: a mainstream commerce engine, a custom front end, and one or two specialist services bolted on where they matter most.

How a headless storefront works, step by step

A simple example helps. A shopper in Manchester opens your site and taps "Add to basket" on a pair of trainers.

1. The storefront (front end) is a separate application. It might be built with a framework such as Next.js or React. It renders the page, the images and the layout.
2. It asks the commerce back end for data through an API call: "give me this product, its variants, its stock status and its price in pounds."
3. The back end answers in structured data, usually JSON, with no layout attached.
4. The storefront decides how to present it. Because your team controls this layer, the design is not constrained by a theme.
5. When the shopper adds to basket, another API call updates the cart held by the back end.
6. At checkout, the shopper is typically handed to a hosted checkout or a payment provider's secure components, so card data is not handled by your own front end.

On Shopify, for instance, the Storefront API supplies products, collections, search and the cart, then hands customers off to checkout, and Hydrogen is Shopify's toolkit for building the custom storefront, with Oxygen as its hosting. Other platforms offer comparable APIs. Some retailers go further and build the commerce services themselves as custom software, which is a different (and larger) undertaking.

Two practical details matter more than they first appear:

• Secrets stay on the server. Shopify's guidance is blunt that a private Storefront API token is a secret and must "Never" be exposed in client-side code or a mobile app. The same principle applies to any platform: your front end needs a server-side layer for anything sensitive.
• Someone has to own the glue. In a theme-based shop, search, reviews and tax widgets arrive as apps that "just work". In a headless build, each of those connections is code that somebody writes, tests and maintains.

What headless commerce can give you

Let's be fair about the upsides, because they are real when your situation fits.

Design and performance freedom. With no theme in the way, your designers and developers can build exactly the experience you want, and tune it for speed. Speed is measurable. Google's Core Web Vitals define "good" at the 75th percentile of page views as LCP of 2,500 ms or less, INP of 200 ms or less and CLS of 0.1 or less. A custom front end gives you more control over reaching those numbers, though it does not guarantee them. A badly built headless site can be slower than a good theme.

One back end, many channels. The same catalogue and basket logic can feed a website, a mobile app, in-store screens and marketplace feeds. For a retailer with physical shops and an online presence, that consistency is a genuine operational benefit. If you also sell through marketplaces, our piece on inventory and order management automation for multi-channel sellers covers the stock-sync side of the problem.

Easier swapping of components. Mastercard's guide notes that integrating new tools such as payment gateways or search providers becomes easier, reducing vendor lock-in. If your search provider disappoints you in two years, you replace one service, not the whole shop.

Independent release cycles. Front-end and back-end teams can ship on their own schedules. A campaign page, a new landing experience or a redesign of the basket does not have to wait for a platform upgrade.

Room for personalisation and testing. Because you control how data becomes pixels, you can wire in experimentation and personalisation tools more deeply than most themes allow.

What it costs you (the part sales decks skip)

The honest list of downsides is just as important.

More to build and more to run. Shopify itself says it plainly: "A headless storefront costs more to build and run than a theme." It also advises confirming that the merchant accepts that extra cost and has developers to maintain the storefront after launch. That advice is worth printing out and pinning above a decision meeting.

You inherit features you used to get free. Themes and apps usually handle things like SEO basics, structured data, redirects, image handling, preview modes and checkout extensions. In a headless build, each one is a line item. Skipping them quietly is how headless projects launch with worse organic search performance than the site they replaced.

Dependency on developers. Crystallize, itself a headless vendor, lists developer dependency as the main drawback in its own guide to when headless is worth it. Content editors who were used to dragging blocks around in a theme editor may need a new editing tool, and Mastercard's guide points out that business teams need a management interface which may have to be built if the platform doesn't provide one.

Closer alignment between marketing and engineering. When the storefront is code, a seemingly small change to a banner or a promotion rule can involve a developer. Teams that work well together thrive. Teams that already struggle may find the gap widens.

More surface to secure and monitor. More services mean more credentials, more integrations and more places for an outage to hide. You need monitoring, logging and a clear owner for each piece.

A note on sources: vendors have a commercial interest in this topic, so treat claims about conversion rates, security or performance with caution unless they come with independent measurement. We have deliberately not quoted market-size or uplift figures here, because the ones in circulation rarely trace back to a verifiable primary source.

Headless versus a good theme: a side-by-side view

Neither column is "better". They are different bets.

When headless makes sense

Based on how experienced practitioners frame it, headless tends to earn its keep when several of these are true at once:

• You sell on more than one surface (web, app, stores, kiosks) and want one source of truth for products and baskets.
• Your current platform's front-end limits are demonstrably costing you, for example because a key journey cannot be built or release cycles are slow.
• You have, or are prepared to fund, engineering capacity for the long term, not just for launch.
• You have a clear content and data strategy, so you know where product information lives and who maintains it.
• Your business is established enough that you are optimising a proven model, not still searching for one.

Crystallize's list of situations where headless is not the right call is the mirror image: a small catalogue with limited customisation needs, no developer capacity or budget to maintain custom front ends, a preference for an all-in-one platform, no clear content and data strategy, or a business still validating product-market fit.

If you recognised your business in the second list, a theme is not a compromise. It is the sensible choice, and you can revisit headless later.

What UK and Australian retailers should check before committing

The architecture is global, but the rules you operate under are local. These are the areas where we see retailers get caught out. We are engineers, not lawyers, so treat this as a prompt for your own legal advice.

Cookies and tracking in the UK. A custom storefront means your own team now controls which scripts load and when. In the UK, rules on storing or accessing information on a visitor's device sit in PECR. The Data (Use and Access) Act 2025 adds new exceptions, such as for statistical purposes and for adapting a service to a user's preferences, but, according to a Clifford Chance briefing from September 2025, those exceptions apply once commencement regulations are made and the ICO's guidance was still in draft at that point. Check the ICO's current position before you finalise your consent design. For a broader look at privacy obligations in custom builds, see our guide to data privacy compliance for ecommerce software.

Consumer-law behaviour in the checkout. Price display, subscription terms and urgency messaging are all things a custom storefront controls. Because you write the interface, you are responsible for getting them right. Our article on engineering checkout for consumer law in the UK, Australia and the US walks through how those rules turn into build requirements.

Currency, tax and delivery. UK retailers deal with VAT and Royal Mail or courier cut-offs, while Australian retailers deal with GST and long domestic distances. Make sure your back end, not just the front-end display, handles the calculations, and that your storefront reads them rather than reimplementing them.

Payment handling. Keep card data out of your own front-end code by using your payment provider's hosted or embedded components. This keeps your compliance scope smaller and is the approach most platforms recommend.

Hosting and latency. If your customers are in London and Sydney, ask where the storefront is served from. A front end deployed close to users can help the performance metrics discussed above, which is one of the genuine arguments for going headless.

A practical path: how to approach a migration

If the checklist above points towards headless, you can reduce risk by not doing everything at once.

1. Measure the present. Capture current Core Web Vitals, organic traffic by template, conversion by device and a list of the apps your theme relies on. Without a baseline you cannot tell whether the project helped.
2. Inventory every feature your theme gives you silently. Redirects, sitemaps, canonical tags, structured data, search, filtering, gift cards, discount logic. Decide for each: rebuild, replace with a service, or drop.
3. Choose the commerce engine and the front-end approach separately. The engine decides your data model and API limits. The front end decides your team's day-to-day experience. Review the engine's APIs against your real requirements, not a demo.
4. Start with one slice. Many teams launch a new product page template or a campaign landing area first, behind the existing site, and learn from real traffic before moving the whole catalogue.
5. Plan the editing experience. Decide how merchandisers will update content and who is on call when something breaks.
6. Budget for year two. The cost is not only the build. Frameworks release updates, APIs version, and integrations drift. Put maintenance in the plan from day one.
7. Run both in parallel for a period. A staged switch with a rollback path is far safer than a big-bang launch before a sales peak.

For a view of the longer-term cost trade-off, our total cost of ownership comparison of SaaS ecommerce platforms and custom development is a useful companion. And if conversion at the basket is your driver, read reducing cart abandonment through custom checkout engineering first, since checkout improvements do not always require a re-platform.

Common mistakes we see

Going headless to fix a problem that is not architectural. Slow sites are very often caused by oversized images, heavy third-party scripts or poor hosting, all of which can be fixed on the current platform. Diagnose before you rebuild.

Underestimating content tooling. If editors cannot preview a page before publishing, trust in the new site evaporates quickly.

Forgetting search engines. A new front end needs rendering that search engines can read, correct metadata and a careful redirect map. This is where the most expensive mistakes tend to happen.

Treating the front end as a one-off project. It is a product. It needs an owner, a backlog and a budget after launch.

Buying composable because it sounds modern. Every extra service is another contract, another API and another failure point. Add components when a specific need justifies them.

Conclusion

Headless commerce is a sound architecture for the right retailer: one with several channels, a distinctive experience to build, and the engineering capacity to look after it. For everyone else, it is an expensive way to rebuild what a good theme already does. The best first step is not a platform demo but an honest audit of what is actually holding your current shop back.

At Syslabs we build custom software for ecommerce and other industries, including storefront and integration work. If you are weighing headless against your current platform, we can help you scope the options, map the trade-offs and plan a staged route. Pricing depends on scope, so we agree it on a consultation.

Book a free consultation – the booking page shows times in your own time zone.