Headless commerce gets discussed as though it is the natural endpoint for serious ecommerce. The implication is that if you are not thinking about going headless, you are behind. That framing has sold a lot of expensive architecture to businesses that did not need it.
The honest answer is that headless Shopify makes commercial sense in a specific set of circumstances. Outside those circumstances, it adds complexity and ongoing cost without a proportionate commercial return.
Here is how to think about it.
What headless actually means
A standard Shopify store uses Shopify's front end and Shopify's commerce engine together. The theme handles how things look. Shopify handles checkout, cart, payments and the merchant dashboard. They are coupled by design.
Going headless decouples the front end from the commerce engine. Your front end is built in a separate framework, such as React, Next.js or Hydrogen, and communicates with Shopify's commerce layer via API. Shopify still handles the cart, checkout, payments and order management. Your front end handles everything the customer sees.
The result is a custom-built front end with Shopify's commerce reliability underneath.
When it makes commercial sense
Front-end performance at very high volume. A custom-built front end in a modern JavaScript framework can deliver faster page loads than a Liquid-based Shopify theme, particularly for large catalogues with complex filtering. If you are running a catalogue with tens of thousands of SKUs and every additional second of load time costs you measurably in conversion, the performance case for headless is real.
Deeply custom user experiences. If the experience you need to deliver is beyond what Shopify's theme system can produce, whether interactive configuration tools, complex product customisation flows or rich media experiences that need to be architected precisely, a headless front end gives you that freedom.
Existing content infrastructure. If you are running a business with significant editorial content in a CMS like Contentful or Sanity, and you need that content and your commerce layer to work together without manual duplication, headless Shopify integrates cleanly with those systems.
Multi-channel or multi-locale at genuine scale. If you are operating across multiple markets with different content, currencies and checkout experiences, a headless architecture managed by a single front-end codebase can be more maintainable than running separate Shopify stores.
When it does not make sense
Most Shopify stores, including most large and complex ones, do not need to go headless.
Shopify Plus with a well-built custom theme is fast. For the vast majority of ecommerce use cases, including catalogues with thousands of SKUs and checkout flows with meaningful customisation, a properly built Liquid theme on Plus performs competitively. The headless is faster argument holds in benchmarks on very large catalogues. For most NZ retailers, the performance difference on a well-built theme is not large enough to justify the architectural complexity.
Headless also introduces ongoing cost. A custom front-end framework requires developers who know that framework. Updates to Shopify's commerce layer that are automatic for theme-based stores require deliberate integration work for headless stores. The maintenance overhead is real and permanent.
Checkout is also worth flagging. Shopify's native checkout remains one of the most conversion-optimised checkout experiences available. Going headless does not change your checkout. The separation of front-end and commerce means your team manages two systems rather than one. That is fine if the front-end capability justifies it. It is an unnecessary overhead if it does not.
The question to ask first
Before deciding whether to go headless, the more useful question is: what specifically does your business need to do that a well-built Shopify Plus theme cannot do?
If the answer is we want faster performance, the next question is whether that performance is actually the constraint. A slow store on a well-resourced theme architecture usually has specific, fixable causes: app bloat, unoptimised images and render-blocking scripts. Those are solved by building well on the existing architecture, not by rebuilding the architecture.
If the answer is we need a custom experience that Liquid cannot produce, that is a more substantive case for headless. It requires specifics. What experience? Why does it need a custom framework? What does that enable commercially?
Webflow as a front end
One architecture worth understanding for businesses that want front-end control without full headless complexity is Webflow as the front end with Shopify handling commerce. This approach gives you Webflow's design and content management capabilities for the primary site experience, with Shopify's cart and checkout handling transactions.
It works well for businesses where the content and editorial experience matters as much as the commerce, and where the product catalogue is managed in Shopify but the brand experience is managed in Webflow. It is covered in more depth in the Webflow Ecommerce vs Shopify article if that is relevant to your situation.
The commercial conclusion
Headless Shopify is the right answer for a subset of ecommerce businesses with specific, justified requirements. For most established NZ retailers, a well-built Shopify Plus store on a custom theme delivers the performance and commercial capability they need without the ongoing architectural overhead.
If you are being told you need to go headless and you are not sure why, that is worth examining before the architecture decision gets made.
Working out what architecture is actually right for your ecommerce build? Let us talk through it.
