Shopify Headless: When It Is Worth the Cost

Last updated October 23, 2026 · By Chad Norris

Disclosure: the author sells Shopify apps under Orbitloft, and those are admin apps, not storefront code. We have not built a headless storefront and this guide is based on Shopify’s documentation, not on a project of ours. See the disclosure page.

The short answer: most stores should not go headless. Shopify’s own documentation says a headless storefront costs more to build and run than a theme and needs developers to maintain it after launch, and that themes and apps are the default path. Headless is worth considering when a theme genuinely cannot do what your business needs: unusual front-end experiences, content from many systems, an app or mobile product sharing the same commerce backend, or a front-end team that wants its own framework.

What “headless” means on Shopify

Headless separates the storefront (the “head” customers see) from the commerce backend. Per Shopify’s headless overview, you build and host the front end with any stack, and Shopify’s APIs supply products, collections, customers, the cart, checkout and international pricing. The overview lists these routes:

• Hydrogen, Shopify’s toolkit for building a full storefront in a JavaScript framework.
• Native mobile with the Storefront API and Checkout Kit.
• Bring your own stack, calling the Storefront API and Customer Account API directly.
• Web Components or Buy Button JS to add products and buy buttons to a site you already have.
• Shopify’s WordPress plugin, to sell Shopify products from WordPress.

The last two are worth noticing. “Headless” is not one decision: adding a buy button to an existing content site is a very different cost than building a custom storefront.

What Hydrogen gives you, and what it leaves to you

According to the Hydrogen documentation (version 2026-10 at the time we read it), Hydrogen adds Shopify-specific commerce logic to a framework you already use: a Storefront API client, cart, variant selection, collection filtering and analytics. It runs on frameworks that execute server code, such as Next.js, React Router, Nuxt, Astro or SvelteKit.

Now the part that decides the budget. The docs say you build:

Everything in a theme that “just works” (sections, SEO defaults, account pages, theme editor) becomes a line item.

Hosting: Oxygen and alternatives

Oxygen is Shopify’s hosting for Hydrogen. Shopify’s headless page says Oxygen is included at no extra charge on supported paid plans, subject to runtime and usage limits, and that Hydrogen can also be self-hosted on compatible infrastructure. The Hydrogen docs describe a React Router template deployed to Oxygen and a Next.js template (Vercel Shop) deployed to Vercel.

One loose end: the developer docs and Shopify’s marketing pages we read disagree about whether the lowest-priced plan is supported, and the page we fetched did not list supported plans. Check Shopify’s current supported-plans list rather than relying on us. Hosting is rarely the main cost; Shopify’s page itself says development, integrations, hosting and maintenance are separate budgets.

The real cost: a checklist, not a number

We will not quote a price range because the sources we read do not publish one and a made-up figure would mislead. Instead, price your own project with this table. Ask a developer or agency to fill in each row for both options.

Shopify’s article warns that your team owns the custom front end, including accessibility, security and API compatibility testing, and that front-end bugs can still interrupt browsing or purchases. Budget for a developer being available after launch, not only during the build.

Who headless is actually for

Headless tends to fit when most of these are true:

• You have a specific front-end experience a theme cannot deliver, and you have tried.
• You already have a development team, or a long-term agency relationship, to maintain code.
• Shopify is one source among several (a CMS, a PIM, a custom configurator) feeding one site.
• You need the same commerce backend for a website and a mobile app.
• The upside of the custom experience is large enough to cover permanent extra cost.

It tends to be the wrong move when:

• Your main goal is “faster” and you have not audited the apps and images on your current theme.
• You are pre-product-market-fit and still changing the catalog and merchandising weekly.
• You do not have an owner for the storefront code after launch.
• A competitor looks fancier. That is not a requirement.

Vendor claims, read with care

Shopify’s headless page cites case-study results, including a brand-reported conversion increase and faster deployment cycles. These are vendor-reported, not independent, and each depends on the brand’s starting point. Treat them as examples of what is possible, not forecasts for your store.

Alternatives to try first

1. Fix the theme. Remove unused apps and heavy scripts, compress images and test on real phones.
2. Use sections and metaobjects for structured content instead of one-off custom pages.
3. Use a buy button or Web Components on a content site you already run.
4. Check app compatibility. If your business depends on apps, see how they behave before changing the front end; our guide to Shopify subscription apps shows how much of a store’s functionality lives in third-party apps.
5. Hire for the narrow job. A theme developer can build one custom section for far less than a full storefront; see how to choose a Shopify agency for scoping advice.

Email, subscriptions and other integrations

A custom front end changes how every third-party feature reaches the customer. Email platforms that rely on onsite scripts for tracking browse and cart events need those scripts loaded by your own code; see our Klaviyo setup order for how onsite tracking works with a standard theme and compare it with what your developer would have to replicate. Subscription widgets, review stars, size guides and search tools are similar: on a theme they are mostly an install and a toggle, and on a headless build each is an integration with its own API and its own maintenance.

That is why a headless estimate should list every app your store uses today and say, per app, whether it works as is, needs a vendor-supplied integration, needs custom work, or gets dropped. If the answer for several revenue-critical apps is “custom work”, the project is larger than the design suggests.

Questions for a developer or agency

• Which parts of our current store will be rebuilt, and which stay as they are?
• Which of our apps work without changes, and who maintains the integration for the others?
• How do you handle SEO: redirects, structured data, sitemaps, canonical tags?
• How will we edit content after launch, and can a non-developer do it?
• Who monitors errors and performance, and what is the response time for a checkout problem?
• What happens when Shopify releases a new API version?

A firm that has done this before answers these specifically. Our guide on choosing a Shopify agency covers how to compare the answers, and our note on Shopify versus Amazon for new brands is worth reading if you are still deciding where to sell at all.

A decision test

Ask three questions in order:

1. What specific customer or business outcome can a theme not deliver? Write it in one sentence.
2. Have we tried to deliver it with theme customization, sections and apps? If not, try that first.
3. If we proceed, who maintains the code next year and what does that cost per month?

If you cannot answer all three confidently, stay on a theme. Confirm current Hydrogen versions, supported plans and hosting limits on Shopify’s Hydrogen documentation before you commit.