Shopify Headless Commerce

WBD is a small e-commerce studio in Oxford. We design and build headless Shopify sites — among the other kinds of store we make — and our first job, when a brand arrives set on going headless, is usually to talk them out of it. 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. An honest page about Shopify headless commerce has to start with both numbers.

If that's where you already suspected you were sat, write to us at hello@wewbd.com and skip the rest — we're platform agnostic (Shopify, WooCommerce, Magento, headless — whatever fits the brand is what we'll build), and we'd rather build you the right thing than the fashionable thing. For everyone else weighing the move seriously, this chapter is the whole picture: what headless actually means on Shopify, the parts you assemble it from, what it costs to run, who it genuinely helps, 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 — and if it's the platform tier you're weighing, the Manual's Shopify Plus Agency chapter is the one you want.

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. That's the rare end of the spectrum, not the default.

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 sensible headless 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. Rebuilding checkout yourself is possible, and it is almost always a mistake. Plan the build around that boundary from the first sketch — getting it wrong is where a healthy share of those first-year failures begin.

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 need a developer within reach — in-house, or an agency you trust. A well-modelled CMS keeps the everyday moves in your team's hands, but anything the CMS wasn't built to expect — a new page shape, a new integration, new checkout logic — is a code change. Brands who go headless without that arrangement regret it within six months.

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 honest 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 honest 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 Shopify build when at least one of these is true:

The brand's identity genuinely can't live inside a theme. This sounds obvious but it's a high bar — most identities can live inside a thoughtfully customised theme. The ones that can't usually involve an unusual product, a non-linear story, or an audience expecting an experience that doesn't look like the rest of the internet.

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 on the engineering genuinely holds — the servicing schedule above, honestly costed against what a faster, freer storefront will actually earn for this brand in this year.

If none of those is true, we say no. We say no more often than yes.

Revenue is under about a million a year. The maths doesn't work; a good custom theme gets you further per pound spent.

There's no developer arrangement and no appetite for one. See the servicing schedule — this one carries a six-month regret timer.

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, a new page shape or a change to how the site behaves goes through a developer. 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? Often the honest answer is yes.

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.