Headless isn't the right call for every brand. We don't default to it, though it is what we prefer. What decides it is how complex your business is, not the architecture. Here's how to figure out which side you're on.
What headless actually means
Headless commerce separates your storefront (what customers see) from your commerce engine (Shopify's backend). Instead of Shopify rendering your pages with Liquid templates, a custom frontend fetches data from Shopify's APIs and renders it independently.
You keep everything Shopify is good at: checkout, payments, inventory, order management. You replace the part that themes handle: frontend rendering, content management and page composition.
Your engineering team controls the storefront, and your marketing team works in a proper CMS rather than the Shopify theme editor. This article is about when that tradeoff is worth making.
The case for headless
Design without constraints
Shopify themes are flexible, but they have a ceiling. Liquid templates, section schemas and the theme editor define what's possible. If your brand needs page layouts, interactions or content structures that don't fit theme conventions, headless removes that ceiling. You build a custom storefront with Shopify powering the commerce layer underneath.
This matters most for brands where the editorial and brand experience is as important as the catalogue. Lookbooks that blur into product pages, scroll-driven storytelling, interactive size guides and video-first product pages with real-time inventory are difficult to build well in a theme and straightforward in a headless build.
Performance control
We build headless storefronts with Astro and Shopify's latest Hydrogen release, hosted on Cloudflare's global network, so pages are rendered on the server close to the customer. If you'd rather keep hosting with Shopify, we can deploy to Oxygen instead.
Headless gives the team control over edge rendering, what JavaScript loads and when, and streaming and progressive rendering patterns that a Liquid theme can't use. Those gains still have to be engineered and measured against your current store.
Content beyond products
If your content strategy includes editorial features, lifestyle content, lookbooks or interactive guides, a headless CMS like Sanity gives your team tools that Shopify's built-in content system can't match.
Every content block in Sanity has a defined schema. A hero section has typed fields for headline, body, CTA and background. An editorial feature has a defined structure for images, pull quotes and product references. Your content team can build and preview pages without touching code.
Multi-storefront architecture
Running multiple storefronts from a single Shopify Plus backend, across brands, markets or channels, is cleaner with headless. Each storefront gets its own frontend while sharing the commerce infrastructure underneath. It also suits agentic commerce, where AI agents work with your structured data and catalogue through Shopify's MCP servers.
The usual case against headless
Cost
The usual line is that headless costs two to three times as much as a theme. Compare like with like and it doesn't. A bespoke headless build costs about the same as a bespoke theme build, and we price them the same. Headless only looks more expensive next to an off-the-shelf theme with light customisation, or next to a quote from cheaper developers. Bespoke work is often easier to build headless, because the frontend isn't working around a theme's structure.
It costs little to run. Hosting on Cloudflare starts at US$5 a month, and Sanity's Growth plan is US$15 per seat per month. See the real cost of going headless for the full breakdown.
Editing after launch
Anything your team can change in the Shopify theme editor, they can change in Sanity. A headless store only needs a developer for everyday changes if whoever built it hardcoded things. We build so that everything your team should be able to change lives somewhere they can change it. For features that used to need an app, a marketing manager can ask Claude to write a script, add it in Sanity and publish the change themselves. We help with larger features, the site's architecture, and anything complex enough that it needs to be built properly to keep the site stable.
Apps
The apps most merchants worry about still work. Reviews are usually a script or an API integration, set up once during the build. Subscriptions work just as well on headless, with a one-time setup and no extra charge compared with a bespoke theme build. Loyalty is usually a script too. Upsells come from the search platform or are curated.
When a theme is the better choice
When the business is simple, when the project is mostly about design with few functional requirements, or when you don't want headless. In those cases headless adds more complexity than it removes. We still build themes, and we respect that call.
A word from our CTO
I came from web app development into ecommerce and found themes restrictive and error prone. It was too easy to make a mistake that overwrote content changes, safe rollback of a deployed feature was much harder to set up, and debugging was harder. From an engineering point of view there's no comparison. Headless isn't the source of complexity. The business is. Headless is better at handling that complexity, because it flows with your requirements instead of fighting them. Max Karlsson, CTO
The hybrid path
There's a middle ground: keep your Shopify theme and run a headless CMS like Sanity alongside it. We've taken this approach with brands like Carwyn Cellars and Byron Bay Cookie Co.
If you're weighing up hybrid against a new build, we'd usually recommend going fully headless. Hybrid makes sense when you already have a theme in place and don't want a full rebuild yet. It sets you up for a rebuild later, but it can also backfire. Where we use it, it's mostly for managing metafields and metaobjects.
The decision framework
Go headless if three or more of these are true: your design team regularly hits theme limitations, your content strategy extends well beyond product pages, you run or plan to run multiple storefronts, measured page speed improvements would materially affect revenue, or you use a search engine like Algolia across search and collection pages.
Stay on a theme if your business is simple, the project is mostly about design with few functional requirements, or you'd rather not go headless. If budget is the constraint, a light customisation of an existing theme is the one build that is actually cheaper.
Consider the hybrid path if you already have a theme in place and aren't ready for a full rebuild. It sets you up for a move to headless later.
The best architecture is one your team can operate and your business can sustain. If you're not sure which path fits, talk to the Flux team and we'll give you an honest answer.
Flux is a Shopify Plus Agency for Advanced Engineering & AEO
- Like for like, a bespoke headless build costs about the same as a bespoke theme, and your team can still make changes without a developer
- Go headless if you need complete design control, content beyond product pages, or multiple storefronts on one backend
- Stay on a theme if your business is simple, the project is mostly design, or you don't want headless
- If you're weighing up hybrid, full headless is usually the better call. Hybrid suits a store that already has a theme and isn't ready to rebuild
