What really changes when the front end leaves Shopify, which costs show up after launch, and the four situations where it's worth it — against the three where it's an expensive trend.
by Nadia Maar ·
"Headless" has become a word that goes into quotes the way an adjective does: it sounds modern, promises speed, and rarely gets explained. In short: the storefront the customer sees stops being the platform's theme and becomes a separate application, which asks the platform for catalogue, prices and cart through its APIs.
It's a serious architectural choice, with real benefits and costs that arrive after launch. This piece is here to help you tell whether your case is one where it pays off — before someone sells it to you as the only way.
In a traditional Shopify store the theme does everything the customer sees: pages, catalogue, cart. In a headless store the storefront is a separate application — with Shopify, usually Hydrogen, its React framework, hosted on Oxygen or elsewhere — and Shopify remains the engine: products, prices, stock, orders, payments.
| Stays with the platform | Moves to your storefront |
|---|---|
| Catalogue, prices and stock | Pages, navigation and search |
| Orders, payments and checkout | Cart and the path to checkout |
| Admin panel | Editorial content, often from a separate CMS |
| Apps that work behind the scenes: shipping, invoicing | Every app that draws something on the page |
Even in a headless store, payment normally happens on the platform's checkout. That's a good thing — it stays secure and up to date with no work from you — but it means you don't design the last step of the journey, and it needs factoring in whenever someone promises a "fully custom" experience.
"What measurable problem does it solve that the theme can't?" If the answer is a percentage of speed, ask on which pages and compared with what. If the answer is "the experience", ask which one, concretely.
A quote for a headless storefront usually describes the build. The real cost has other lines, and they need asking about up front:
If the proposal on the table is a headless storefront, these five questions separate a project that's been thought through from one that's been sold. None needs technical knowledge to ask, and every one deserves a written answer.
Between an off-the-shelf theme and a fully separate storefront there's almost always a space people overlook: a custom theme, built well, with the heaviest parts rewritten. It solves many performance and experience problems with only one system to maintain.
And if the day comes when splitting off is truly needed, a tidy catalogue and a clean theme are the best starting point for doing it. Going headless is reversible only at great cost; a custom theme keeps both roads open.
The choice comes from looking at where the store loses today — speed, conversion, the team's time — not at what competitors are doing.
The free store audit measures exactly this, and tells you which of the three roads makes sense in your case. Even when the answer is that the theme you have is enough.
An architecture where the storefront the customer sees is an application separate from the ecommerce platform. The platform handles catalogue, prices, orders and payments; the storefront requests them through APIs and presents them however it likes.
When the theme is the ceiling for performance or experience, when several storefronts draw on the same catalogue, and when someone will maintain the storefront over time. With a contained catalogue and a theme that works, it usually isn't.
The ones that work behind the scenes — shipping, invoicing, stock — yes. The ones that draw something on the page have to be integrated one by one through their APIs, if they have them.
Normally not: payment happens on the platform's checkout. That's an advantage for security and updates, but you don't design the last step of the journey.