For most Shopify stores, going headless is the wrong decision. Shopify says so itself: its headless documentation states that "a headless storefront costs more to build and run than a theme", and tells builders to confirm the merchant accepts that cost and that developers will be on hand to maintain it after launch.
That sentence deserves more weight than it usually gets in a sales conversation. This post is about where the extra cost lands, which parts of it you can verify and which you cannot, and the narrow set of stores where it earns its keep.
What does "headless" actually mean on Shopify?
You keep Shopify for products, cart, checkout, customers and orders. You replace the theme, the part of the store that renders pages, with a frontend you build and host yourself, talking to Shopify through the Storefront API and the Customer Account API.
Shopify's own toolkit for this is Hydrogen. It adds the Shopify-specific pieces (cart, variant selection, collection filtering, analytics) to a framework you already use, and the docs list Next.js, React Router, Nuxt, Astro and SvelteKit. You are not forced onto Shopify's hosting either; the Storefront API works with "nearly any technology stack".
The important sentence in the Hydrogen docs is the plain one: with Hydrogen, your app owns the UI, routing and data loading, session storage, account pages, images and SEO. Every one of those is something a theme gives you for free.
Is the hosting the expensive part?
No, and this is where most cost conversations go wrong.
Oxygen, Shopify's own hosting for Hydrogen, is available at no extra charge on paid Shopify plans. The same page lists its limits: workers capped at 10 MB with a 400 ms startup limit, 30 seconds of CPU time per request, and 128 MB of memory. It runs on a Workers-style runtime rather than Node.js, which means some Node code will not run unchanged: the Node crypto module behaves differently, and eval() is unavailable. If your build leans on a Node-only library, that is a rewrite.
Two honest caveats. First, that fundamentals page sits under a "legacy" path, and the deployment docs now split by Hydrogen version, so confirm the current wording before you quote it to a client. Second, the same page says the number of public environments varies by plan and does not state the numbers. If you need several public storefronts, such as separate markets or staging that clients can open, find out the limit for your plan before you design around it.
If you host elsewhere, say on Vercel because your frontend is Next.js, the platform bill is still small by the standards of a store's revenue. Vercel's pricing page lists Pro at $20 a month with a $20 usage credit, 10M CDN requests and 1 TB of data transfer included, then pay-as-you-go beyond that. Hobby is for non-commercial use only, so a real store cannot run on it.
So hosting is somewhere between nothing and a modest monthly platform bill. If someone's quote is dominated by hosting, ask what else is in it.
Where does the money actually go?
Into rebuilding what the theme did for you, and into people to maintain it. Shopify does not publish a figure for either, and we are not going to invent one. What we can do is list the line items so that you can ask a vendor to price each.
| Line item | Theme store | Headless store |
|---|---|---|
| Page layout and design | Theme and theme editor | Built and tested in code |
| Merchandising changes by the marketing team | Theme editor, same day | Needs a developer, or a CMS you also have to buy and integrate |
| Apps (reviews, subscriptions, bundles, loyalty) | Install from the app store | Many assume a theme; each needs an API route or a rebuilt component |
| SEO basics | Theme handles it | You return SEO data from each route and supply the JSON-LD yourself |
| Redirects | Shopify admin | You build or verify them; the Hydrogen SEO guide does not cover them |
| Customer accounts | Built in | Built on the Customer Account API |
| Ongoing changes | Merchandiser | Developer sprint |
That last row is the one that bites. The cost of headless is mostly not the first build. It is that every future change to the storefront becomes an engineering ticket.
Two details from the docs show how much is on you. Product URLs default to /products/:handle, and if your structure differs you must add server-side redirects. And Hydrogen's SEO helpers cover meta tags, canonical URLs, a sitemap route and robots.txt, but the structured data content for each route is yours to supply.
What about speed? Isn't that the whole point?
It is the most common reason people give, and the evidence for it is weaker than the pitch.
A well-built headless storefront can be very fast. A well-built theme store can also be fast. In our audits, slow Shopify stores are usually slow because of third-party apps, tracking scripts and oversized images rather than the theme itself, and a headless build that reinstalls the same scripts is slow in the same way. The fixes for that are almost always cheaper than a rebuild.
We have not found a Shopify-published benchmark that compares like-for-like theme and Hydrogen stores, and we would distrust any agency number that did not say what it was measured against. If someone promises a specific speed or conversion uplift from going headless, ask for the before-and-after on a store with a comparable catalogue and app stack.
Which stores does headless genuinely pay off for?
Shopify's docs name the situations where it is the right call, and they are narrower than the marketing suggests:
- A storefront experience the existing tools cannot easily support
- A frontend stack that does not use Liquid, usually because a team already has one
- Adding Shopify commerce to existing infrastructure
- Selling on channels Shopify does not support out of the box
- Using a separate CMS for storefront content
Translated into the kinds of businesses we meet:
A content-heavy brand where the editorial site is the business. If the content team already runs a CMS and the shop is a section of a much larger site, one codebase beats two.
A catalogue with a configurator or unusual buying flow. Made-to-order, build-your-own bundles, heavily dynamic pricing. The cart is no longer a standard cart, and a theme will fight you.
Several storefronts on one backend. Multiple brands or regions sharing inventory and operations, where a theme per store means repeating the same work.
A team that already ships software. If you have in-house engineers and a deployment process, the maintenance burden is not new. This is the strongest single predictor in our experience, because the cost that matters is people, not platforms.
What is notably absent: "we want a faster site", "we want a custom look" and "our agency recommended it". A custom look is possible in a theme with a good developer. Speed is mostly an apps-and-images problem.
When should you not go headless?
Do not go headless if:
- Your marketing team changes the storefront weekly. Promotions, banners, new landing pages. In a theme that is an editor session. Headless makes it a developer task unless you add a CMS, which is another integration to buy and maintain.
- You depend on a stack of storefront apps. Check each one. Many were built for themes and have no headless equivalent.
- Nobody will own it. A headless store with no developer behind it degrades quietly: dependencies age, an API version is retired, and one day checkout links break. Hydrogen is versioned, and the deployment docs already distinguish releases before and after 2026-10.
- You are under a certain scale and cannot say what it will return. We deliberately do not give a revenue threshold. We have not seen a defensible one, and anyone quoting a figure is guessing. The test is simpler: can you name the specific capability a theme cannot provide, and what that capability is worth in rupees a month?
- The real problem is the catalogue or the checkout. Both live in Shopify either way. Headless changes neither.
If your honest answer is "the site feels dated and slow", the cheaper sequence is: audit the apps, fix the images, then redesign the theme. That is a smaller project and it solves most of the problem.
What should you ask a vendor before agreeing?
- Which theme features and which of our installed apps will you rebuild, and which will we lose?
- Who handles redirects from our current URLs, and how will we confirm nothing dropped out of search?
- What does a normal content change look like after launch? Who does it, and in how long?
- Where is it hosted, what are the runtime limits, and what happens if we need a Node library?
- Who owns the code and the hosting account?
- What is the monthly cost to keep it running and updated, separate from the build?
The last question is the one that separates a build quote from a business case.
Where Cloud 9 comes in
We build both kinds. Our Shopify development work is mostly themes, because that is what most stores need, and we say so when it is true. We take on headless when one of the situations above genuinely applies, usually as part of wider e-commerce engineering where the storefront connects to inventory, ERP or custom workflows. For reference ranges on the broader site-build side, see our website development cost guide.
If you are weighing it up, tell us what the storefront needs to do. If a theme can do it, we will say that, and it will cost you less.
Bharat Vasireddy
Founder & Digital Marketing Strategist8+ years of experience in performance marketing and web development. I help businesses scale through data-driven SEO, Google Ads, and high-performance websites.