"We should go headless."
I hear this sentence regularly during audits. Often right after a meeting with an agency that promised an "ultra fast" site with "no limits". And every time, the same question sits behind it: what is it exactly, and is it for me?
Short answer: for the vast majority of Shopify stores, no. But for a few specific profiles it's the right tool, and you might as well know which ones. Here's the full tour, with real budgets and the traps the sales decks leave out.
What headless means, concretely
On a classic Shopify store, Shopify does everything: it stores your products and orders, and it also generates the pages your visitors see, through your Liquid theme. The back office and the storefront are one single block.
Going headless means cutting that block in two. Shopify keeps the back: catalog, inventory, orders, payment. And you build the storefront yourself, as an independent web application that fetches the store's data through the Storefront API.
Hence the name: "headless". The "head" is the front end. You remove it from Shopify and build it custom.
Hydrogen and Oxygen: the official stack
Hydrogen is the framework Shopify provides to build that custom storefront. It's React, built on React Router 7 (the heir of Remix, which Shopify acquired in late 2022), with the e-commerce parts already wired: cart, Storefront API connection, caching, analytics.
Oxygen is the hosting that goes with it. Shopify deploys your Hydrogen front on its own infrastructure, at no extra cost on paid plans. You can also host elsewhere (Vercel, Cloudflare) or build with another framework like Next.js: the Storefront API doesn't force anything on you.
One point that tends to reassure people: even headless, the checkout stays Shopify's. The payment tunnel, the most sensitive part of your store, doesn't move.
What you gain
Total control of the front end. No more imposed theme structure, no more Liquid limits. Page transitions, animations, layouts that break out of the e-commerce mold: everything becomes possible, because it's your application.
Multi-storefront. A single Shopify back end can feed several storefronts: one per country, one per brand, a mobile app. For a group running 4 brands, that's a real argument.
Rich content. You plug in a dedicated CMS (Sanity, Contentful) and your editorial team publishes pages that blend storytelling and products, without bending a theme's sections out of shape.
And potentially excellent performance, with server-side rendering and fine control over every kilobyte that ships. I insist on "potentially", we'll come back to it.
What you lose (and what nobody mentions upfront)
The theme editor, first. On a classic theme, your marketing team moves a section, swaps a banner, launches a promo on a Friday at 6pm, without a developer. Headless, all of that is gone. You have to rebuild it, usually through the CMS, and every editable block is billed dev time.
A big chunk of your apps, next. Everything that injects itself into the theme (reviews, upsells, bundles, popups) stops working as is. Either the app exposes an API and you re-integrate it by hand, or you switch tools. On a store running 15 apps, this line alone can double the quote.
Technical SEO also starts from zero. Sitemap, structured data, canonicals, hreflang, OG tags: everything the theme handled silently becomes your code, so your responsibility, including when it breaks.
And maintenance. A well-built custom theme runs for years with almost no intervention. A headless front is a React application in production: dependencies to update, framework version bumps, monitoring. That cost never stops.
The performance misunderstanding
It's the number 1 sales argument: "headless is faster". In theory, yes. In production, not always, and I've seen the opposite.
A React front ships hydration and client-side JavaScript. Poorly handled, that means a degraded INP and sluggish interactivity, exactly the problem I describe about INP on Shopify stores in 2026. The framework protects you from nothing: it just moves the responsibility for performance from Shopify to your team.
Meanwhile, a clean Liquid theme hits 90+ on Lighthouse without any exotic architecture. If your store is slow today, the cause is almost always more mundane: stacked apps (here's their real measured cost), heavy images, third-party JS. That gets fixed by working on the existing theme, for a fraction of the price of a headless rebuild.
Going headless for speed, without treating those causes first, is buying a race car because yours has flat tires.
The real budgets
The ranges I see on the market, to be read as orders of magnitude:
- A polished custom theme: €5,000 to €15,000, with near-zero maintenance afterwards.
- A serious headless build by an agency: €30,000 to €100,000 and up, depending on scope (CMS, apps to re-integrate, multi-country).
- Headless maintenance: plan for a recurring dev budget, often €1,000 to €3,000 per month depending on how fast you evolve.
The ratio to remember: a headless project costs 5 to 10 times more than a custom theme, for the same functional scope. Something measurable has to pay for that difference.
Who should go for it
Some profiles genuinely justify headless:
- Brands with dense editorial content, where storytelling carries the conversion and the theme becomes a straitjacket.
- Multi-brand or multi-country groups, pooling one Shopify back end behind several storefronts.
- Experiences Liquid can't do: complex product configurators, virtual try-on, a web app embedded in the buying journey.
- And in every case, a lasting dev team or budget. A headless store without a developer on hand is a store frozen in the state it was delivered.
In practice, below a few million euros of annual revenue, I struggle to see the return on investment. Above that, with one of the needs listed, the conversation gets serious.
Who should skip it
Almost everyone else. If your motivation boils down to "I want a faster site" or "I want a prettier site", a custom OS 2.0 theme does the job for 5 to 10 times less, while keeping the theme editor, the app ecosystem and SEO that works on its own.
One piece of advice if headless is still in the back of your mind for later: clean up your data structure now. Tidy product sheets, well-thought-out metafields, a coherent taxonomy. The day you swap the front end, the back won't have to move.
How I settle it in an audit
Three questions, in this order:
- What do you want to do that your theme can't? If the answer stays vague after 5 minutes, the topic is closed.
- Who maintains the front in 18 months? A name, a contract or a team. Otherwise it's a no.
- Does the expected gain cover a budget 5 to 10 times higher? With a number attached, not a hunch.
Three solid answers, and headless deserves a quote. One that wobbles, and there's probably €20,000 to be saved.
If you're on the fence about your own store, this is exactly the kind of call I make in an audit: I look at what's actually holding your site back, and I tell you whether the answer is called Hydrogen or whether it fits in 3 weeks of work on your theme. You can also see the kind of projects I deliver in my portfolio section.
