No ceiling on the front end
Anything you can build in React, you can ship. The theme stops being the thing that decides what is possible.
HEADLESS COMMERCE
Go headless when the storefront is the constraint — not before
Headless decouples the storefront from Shopify’s theme layer: Shopify keeps the catalogue, cart, checkout and orders, and a front end you control renders everything a customer sees. It buys freedom and costs simplicity, so the first job is deciding whether you need it at all.
IN SHORT
- Headless means Shopify keeps the catalogue, cart, checkout and orders while a front end you own renders everything the customer sees.
- Most stores asking about headless have a theme problem or an app problem, and both are cheaper to fix than a rebuild.
- The real cost is not the build. It is owning a codebase, losing the theme editor, and replacing every app that works by injecting a script.
- Hydrogen with Oxygen hosting is the lowest-risk route, because Shopify supports the framework and the hosting is included on Plus.
- Checkout should stay on Shopify in every case — it carries PCI scope and converts better than anything you would build.
Start by not going headless
Most conversations that begin with “we’re thinking about headless” are really about something else. The store is slow. The theme has been extended by four agencies and nobody wants to touch it. Marketing waits a week for a landing page. Those are real problems, and none of them requires replacing the rendering layer.
A speed programme fixes the first, a theme rebuild fixes the second, and a section library fixes the third — each for a fraction of the cost, and each reversible. Headless is worth it when the front end is genuinely the constraint, and that is a narrower case than the marketing around it suggests.
What headless actually means
Headless commerce
Splitting the storefront from the commerce platform. Shopify keeps products, inventory, cart, checkout and orders; a separate application renders the pages and talks to Shopify through the Storefront API. The “head” that is removed is the theme layer — Liquid templates and the theme editor that comes with them.
When it is the right call, and when it is not
| Stay on Liquid | Go headless | |
|---|---|---|
| Your storefront is slow | Almost always the answer — the cause is usually apps and images, and both survive a replatform | Only if the theme itself is unfixable, which is rare |
| You need a complex configurator | Workable up to a point, with a custom app doing the heavy lifting | Right call once the interface stops fitting inside a product page |
| One front end for web and native app | Not possible — Liquid renders web pages only | This is the strongest case for headless there is |
| Content comes from several systems | Possible with metafields, awkward beyond a certain volume | Right call — composing sources is what a headless front end is good at |
| Merchandisers publish their own pages | Theme editor does this for free | Costs you a CMS, a content model and a migration of everyone’s habits |
| You have no in-house front-end team | The safe choice — a theme can be handed to any Shopify developer | Risky. You now own a codebase, and the pool of people who know it is you |
How we run a headless project
- 01
Establish what is actually wrong
A slow storefront, a design the theme cannot express, and a merchandising workflow nobody likes are three different problems with three different fixes. Only one of them is solved by going headless, and it is the rarest of the three.
- 02
Price the whole thing, not the build
Front-end engineering, a CMS, replacements for script-injected apps, and a team that can maintain a codebase after launch. The build is usually the smallest line on that list.
- 03
Choose the stack
Hydrogen and Oxygen if there is no strong existing preference. The Storefront API directly if your team already runs a framework well, or the storefront is one surface inside a larger application.
- 04
Decide where content lives
Leaving Liquid means losing the theme editor. Editorial content moves to a headless CMS, products stay in Shopify, and the front end composes both. Deciding this late is the most common way these projects stall.
- 05
Build against the real catalogue
Filtering, pagination and search behave differently at ten thousand SKUs than at fifty. Load-test the queries during the build, because the Storefront API bills by query cost and throttles designs that ignore it.
- 06
Cut over by route
Move the templates that justify the project first and leave the rest on Liquid until they earn the move. A partial headless site is a legitimate destination, not a failed migration.
What you get, and what it costs you
One front end, many surfaces
Web, native app and in-store screens can share components and data instead of each getting its own build.
Content and catalogue stop blocking each other
Editors publish in the CMS, merchandisers work in Shopify, and neither waits on a developer to ship a page.
You own a codebase now
That is the cost, stated plainly. It needs maintenance, dependency updates and people who understand it, indefinitely.
Before you commit, check these
- List every app that injects a script into your theme — reviews, popups, personalisation, analytics. Each one needs a replacement, an API integration, or a decision to drop it.
- Name who will publish a landing page on the Tuesday after launch, and in which tool.
- Agree a performance budget in numbers, and agree who gets to block a release for breaking it.
- Confirm checkout stays on Shopify, and that nothing in the plan quietly assumes otherwise.
- Decide who maintains the front end in year two, and whether that person is currently employed here.
Custom front-end work we have shipped
We have not yet taken a client fully headless, and we would rather say so than imply otherwise. What we have built is the hard part of these projects on Shopify itself: a bundle builder for Tayst that captures a multi-step configuration and pushes it into Recharge subscriptions, the Find Your Moon tool for Moonglow that renders a moon phase from a date and drives a personalised product, and a capacity engine for Eat Cake Today where vendor lead times decide which delivery slots a customer can pick at checkout.
Those are the interfaces people usually go headless to build. Knowing when they fit inside Shopify is why this page spends most of its length talking you out of the rebuild.
Who we have done this for
Clients from the roster whose work this page describes. Each links to what we actually built.
Tayst Coffee
A guided bundle builder for a coffee subscription: the customer answers what they drink, how many drinkers there are, which roast they want and how many cups, picks their cups, and the built bundle is handed straight to Recharge.
Moonglow
Moonglow sells jewellery set to the moon phase of a date that matters to you. We built Find Your Moon: the customer enters a date of birth or other significant date, the store renders that moon phase, and it drives the personalised product.
Eat Cake Today
A cake marketplace connecting customers to vendors across Malaysia. We built the back end that decides what can actually be delivered: each vendor has a daily capacity and each cake a lead time, and together they determine which dates and time slots a customer is offered at checkout.
Headless Shopify questions
What is headless Shopify?
An architecture where Shopify continues to run the catalogue, cart, checkout and orders, but the storefront a customer sees is a separate application you build and host, reading data through the Storefront API instead of rendering Liquid templates.
Do we need headless Shopify?
Probably not. Headless earns its cost when the front end is genuinely the constraint — a configurator Liquid cannot express, one front end shared across web and native app, or content composed from several systems. If the complaint is page speed or an unwieldy theme, fixing those directly is faster, cheaper and reversible.
Is headless Shopify faster?
Not automatically, and plenty of headless builds are slower than the theme they replaced. A headless front end removes the theme and app scripts that usually cause the problem, but it replaces them with a JavaScript bundle that can be just as heavy if nobody sets a performance budget and holds to it.
What does headless cost us operationally?
The theme editor, most apps that work by injecting a script into your theme, and the ability to hire someone who already knows your stack. In exchange you get a front end with no ceiling. That trade is worth making far less often than it is made.
Does checkout stay on Shopify?
Yes, in every build we would recommend. Shopify Checkout carries the PCI scope, handles local payment methods, and converts better than a custom equivalent. Rebuilding it is possible on Plus and is almost never a good idea.
Can we go headless for part of the site?
Yes, and it is usually the better plan. Serving product pages from a headless front end while collections and content stay on Liquid limits both cost and risk, provided the two halves are treated as one site for URLs, analytics and internal linking.
Where to go next
Hydrogen & Oxygen Builds
Shopify’s own React framework and hosting — the shortest path to headless that keeps you inside supported territory.
Storefront API Front Ends
A custom front end on Next.js or your existing stack, reading catalogue and cart from the Storefront API.
Headless CMS Integration
Editorial content in Sanity or Contentful, product data in Shopify, composed into one front end without either team blocking the other.
Liquid to Headless Migration
Moving an existing theme to a headless front end without losing URLs, SEO or the merchandising your team relies on.
NEXT STEP
Free store audit
Most stores that ask about headless have a theme or app problem instead. A senior engineer will tell you which one you have, at no cost.