Shopify Headless Commerce

WBD is a small e-commerce studio in Oxford. We design and build headless sites — Next.js and Sanity, with Shopify underneath or not — and it's the work we're proudest of, because it's work that feels as close to real craft as it gets in the digital world. The industry's own research says roughly three out of four brands who ask for a headless build are better served by a well-built traditional store, and roughly four in ten mid-market headless projects fail inside their first year. Both numbers belong on this page, and so does our reading of them: the projects that fail were started for the wrong reasons — a templated feeling, a checkout that looked like Shopify's — and the test that separates the three from the one is whether the site is a product.

If the site is a channel — a place to put a catalogue a theme can hold — a well-built theme is the cheaper answer and we'll build you that instead; write to us at [email protected] and skip the rest. If character, content and craft are what you sell, and the site is the shopfront for all three, this chapter is the whole picture: what headless means on Shopify, the parts you assemble it from, what it costs to run, what it buys, and how Shopify's own tooling compares with a fully custom build.

Two neighbouring conversations, so you're on the right page: whether to leave Shopify altogether is a different question — that argument lives in When (Not) to Leave Shopify — if it's the platform tier you're weighing, the Manual's Shopify Plus Agency chapter is the one you want — and if the engine itself is in question, Avoid the Fight covers the open-source route.

A normal Shopify store is one connected thing. The storefront your customer sees — product pages, imagery, typography, the visual layer of the shop — and the engine underneath — catalogue, inventory, orders, payments, customer accounts — are married inside the platform. Monolithic, in the jargon, which is the unkind word for "the design and the database know each other intimately."

That marriage is a genuinely good deal for most businesses: pay the fee, get a working shop. The trouble starts when your idea of the shop stops fitting inside what the theme system was designed for. The checkout looks like Shopify's checkout, the page builder allows what the page builder allows, and everything beyond that becomes a workaround. That's the moment the headless conversation usually starts.

Going headless splits the store in two. Shopify stays on as the commerce engine — the products, the orders, the payments, the heavy lifting — and the storefront becomes a separate application you build and own, talking to Shopify through its Storefront API. The front asks the back for a product; the back replies. The front sends an order; the back processes it. That's the entire idea, and everything else on this page is consequences.

One misconception to retire early: you don't need Shopify Plus to go headless. The Storefront API is there on standard plans, and so is Shopify's own headless tooling. Plus adds higher API limits and deeper checkout control — worth having at scale — but it isn't the price of entry, whatever the pitch deck implied.

A headless storefront is roughly four parts bolted together:

Plug those four together with API calls and you have a headless Shopify site. Each part can be swapped without rebuilding the whole — the long-game argument for the architecture, and a genuine one when the roadmap calls for it.

Inside the decision sits a second fork: Shopify's own tooling, or a stack you choose yourself.

Hydrogen and Oxygen are the paved path. Hydrogen is Shopify's React framework — built on Remix, not Next.js, a detail plenty of explainers get wrong — and Oxygen is the first-party hosting underneath it. The pair is tightly coupled to Shopify, which is both the pitch and the constraint: sensible defaults and first-party support, in exchange for doing things Shopify's way.

A custom stack trades that convenience for freedom. Next.js and Sanity on a host of your choosing — nothing about the storefront dictated beyond the API contract. It's more to own, and it's the right choice when the brand needs a storefront no framework's defaults were designed for. It's the way we build.

There's a third fork we'll name because we've walked it: leaving Shopify's engine behind entirely. Pegoretti — the case study we wrote up — runs Next.js and Sanity with a commission flow written from scratch, no Shopify anywhere, because you don't add a hand-built Italian frame to a cart. You contact the Bottega and discuss the build. Blind John's Guitars walked the same fork more recently: relic electrics made one at a time in a Suffolk shed, the same stack, a commission flow that starts with how you play. With a real catalogue behind the same kind of site, the engine would be Medusa, the open-source one, and the checkout would be code you own. It's the end of the spectrum where our best work lives.

Shopify's checkout is one of the best-converting on the internet, tuned by more testing than any of us will run in a lifetime. A headless Shopify build keeps it: your storefront handles the browsing and the story, and at the money moment the customer is handed to Shopify's checkout, which does what it's brilliant at. Rebuild it yourself on Shopify and you've paid for the platform and thrown away its best part, so plan the build around that boundary from the first sketch. The exception is the business whose sale isn't an add-to-cart at all — a commission, a build slot. Then the checkout is the product, it belongs in your code, and Shopify may not belong underneath: that's the Pegoretti and Blind John's route, and with a catalogue, the Medusa one.

Headless moves work Shopify used to absorb quietly back onto your side of the ledger. On a themed store, Shopify maintains the storefront layer and patches it in the background while you sleep. Headless, the whole front of the shop is yours: the framework updates, the hosting, the API connections between the parts. That's an ongoing commitment, not a one-off build cost.

You'll want a developer within reach — in-house, or an agency you trust — and fewer hours of one than the industry figures imply. A site made well, properly researched and built around the problems the business actually has, doesn't need a developer often, and hardly ever to fix things. A well-modelled CMS keeps the everyday moves in your team's hands: new pages, new modules, a campaign, the journal. What goes through a developer is a new feature or a new integration — which is exactly what goes through a developer on Shopify too, along with any page that steps outside the theme. The difference is who owns the code when you call.

The published industry numbers for a maintained headless site — two to eight thousand a month — were written before this generation of AI development tools landed, and the update is that the floor has dropped: the current toolkit compresses experienced engineers' time meaningfully, and a store doing a million a year can now sometimes carry a build where two million was the old floor. Worth being equally clear about what those tools are: compression, not substitution. They don't replace the architecture decisions, the taste, or the senior judgment that keeps a production store upright when something breaks at 3am. If anyone tells you a headless site can be AI-built end to end without humans in the loop, walk away.

And the architecture guarantees nothing. A badly built headless site is slower and more fragile than a good Shopify theme. Headless raises the ceiling — reaching it is still craft.

Speed, of the kind that moves money. A well-built headless storefront served from the edge turns three-second pages into three-hundred-millisecond ones, and conversion responds to that measurably.

A content team that moves at the pace of the marketing calendar. The CMS puts homepage modules, journal posts and campaign pages directly in your team's hands. Edit, publish, live in thirty seconds — no ticket, no deploy. This bit alone has paid back the build for more than one of our clients.

An app, not a theme. The part most explainers undersell: your site becomes a piece of software your business owns. An unusual flow, a custom integration, a new way of selling — you can simply build it. The code is yours, the data model is yours, the shape of it is yours. For brands that think of the site as a product rather than a tool, this is what they came for. (You do, of course, still have to build the thing.)

We say yes to a headless build when at least one of these is true:

The site is a product. Character, content and craft are what the brand sells, and the site is where all three are met. A thoughtfully customised theme can carry a lot of identities; it can't carry a non-linear story, or an audience expecting something that doesn't look like the rest of the internet. Makers, mostly — the brands we're built for.

More than one channel needs to share the engine. Web shop plus wholesale portal plus app plus in-store POS, all pulling from one catalogue and one inventory. The engine sits in the middle; the fronts multiply around it.

The maths holds — the servicing schedule above, costed against what a faster, freer storefront and a team that can publish without a ticket will earn for this brand.

If none of those is true, we'll say so, and build you the theme.

The site is a channel, not a product. A catalogue a theme can hold, a first store, a founder happy in the admin. A good custom theme gets you further per pound spent, and there's no shame in it.

Nobody wants to own it. A headless site is software the business owns, and someone has to like having the keys — not a developer on retainer, a team that wants the site to be theirs. If owning it sounds like a chore, rent one.

The problems are creative, not technical. New design, new copy, new photography, a better product structure — all fixable on the platform you already have, for a fraction of the cost. This is the most common case we see, and we've talked plenty of brands out of the replatform and into doing the creative work properly.

The pitch you're hearing leads with "scale" and "future-proofing." Fine words, routinely used to sell builds that won't pay for themselves for years. If the agency can't say what headless unlocks for your business in the next twelve months, they're selling architecture for its own sake.

What running one is actually like, since almost nobody writes this part down. Editorial is lovely: your team edits a block, hits publish, it's live in half a minute. Operations don't change at all — products, stock and orders live in the Shopify admin exactly as before, and the ops team barely notices the move. What changes is the storefront's relationship to novelty: there's no app store for your frontend, so a new integration or a new way for the site to behave goes through a developer — as it would on Shopify, where anything outside the theme does too. New pages, by contrast, get easier: the CMS was modelled for them, and nobody is waiting on a theme section that doesn't exist. Performance is excellent only if the build is good, and analytics is wired by hand rather than inherited — done well it's fine; done badly it breaks the marketing team's month.

If you're considering the move — or your agency is recommending it — ask three things.

One. What specifically does going headless unlock for our business in the next twelve months? If the answer is "scale" or "future-proofing," press for specifics.

Two. What's the total cost of ownership for the first eighteen months, including the ongoing engineering? This number is usually two to three times what brands expect.

Three. What's the design and editorial problem we're actually trying to solve — and could a redesign on our current platform solve it? Sometimes the answer is yes, and it's the cheaper one.

If the case is still clear after those three, go — the work is unbelievably good when it's right. If it isn't, fix the brand and the design first. The platform can wait.