What a headless Shopify build actually costs

Headless is quoted as a build cost. The build is the visible part, and usually not the largest.

The build

A headless storefront replacing a theme is typically a multi-month project in the five figures, and considerably more at enterprise scale. Compare with a custom theme at four to eight weeks — project cost and timeline.

You're building a web application, not configuring a theme. That's more time and a developer who knows React, not just Liquid.

The costs people don't count

Replacing apps. Many Shopify apps inject into Liquid themes and do nothing on a headless front end. Every one you rely on becomes a decision: find a headless-compatible alternative, integrate it via API, or build the feature. On a store with fifteen apps that's a substantial hidden line — custom apps vs third-party.

SEO parity. Server-side rendering, metadata, canonicals, sitemaps, redirect handling, hreflang, structured data — all free with a theme, all built by you now. It's a deliverable with real hours attached, and skipping it costs more traffic than headless gains in speed. Headless SEO.

The theme editor. Merchandisers can no longer rearrange pages, swap banners or run a campaign without a developer. Either you accept that ongoing cost in developer time, or you build editing capability — which is its own project.

This is the cost most often discovered after launch, and it's the one that generates the most regret.

Hosting. Oxygen is included with Hydrogen. A Next.js storefront hosts commercially, and at traffic that's a real monthly number.

Maintenance. A codebase, dependencies, a deploy pipeline, framework upgrades, API version rotation. Budget an ongoing percentage of the build cost per year, the same as any custom app.

What you get back

Being fair about the upside:

• A higher performance ceiling, if built well.
• Freedom in the UI — configurators, unusual navigation, app-like interactions a theme genuinely can't express.
• One front end over several back ends, if you're composing Shopify with a CMS or other systems.
• Multiple front ends on one commerce backend — web, app, kiosk.

When it pays back

Honestly, four situations:

1. Speed is a measured business problem and you've exhausted theme-level fixes. Not "it feels slow" — a measured relationship between speed and revenue, after a proper audit.
2. The storefront genuinely cannot be expressed in a theme. Structurally different, not just nicer.
3. Content or data lives elsewhere and composing it in the front end is the clean answer.
4. You have the team to maintain it. Not just to launch it.

If none of those are clearly true, the money buys more elsewhere.

The comparison that matters

For most stores considering headless, the honest alternatives are:

Row one deserves a serious look first. A performance audit costs a fraction of a headless build and frequently delivers most of the gain — because the store was slow due to twelve apps and unoptimised images, not because Liquid is slow.

The middle path

Run the storefront in Liquid and build one high-value piece against the Storefront API — a configurator, a live search, a fast cart. You get the benefit where it matters and keep the theme editor, the apps and Shopify's SEO handling everywhere else.

This is what most stores that "use the Storefront API" actually do — progressive headless.

The question to answer first

What specifically can't you do today? Write it in one sentence.

If the sentence is about speed, get a performance audit first. If it's about a structural limitation of themes, headless is a real answer. If you can't write the sentence, you're buying an architecture rather than solving a problem.

Headless costs about three times a custom theme to build and considerably more to live with. It's worth it when you can name the constraint it removes — and expensive when you can't.