Most agencies will tell you headless Shopify means Hydrogen. They're wrong — or at least, they're only telling you the part that's convenient for them to tell you.
Shopify built Hydrogen to accelerate adoption of headless architecture. It works. It's well-engineered, and Oxygen hosting is free on almost every plan. If Shopify's incentive is to keep you deep inside their ecosystem, Hydrogen is the mechanism. That's not a criticism — it's just the context you need to evaluate the advice you're getting.
We've built headless storefronts on Hydrogen and on custom Next.js stacks. We've also built on Centra, which is a different class of infrastructure problem entirely. From that vantage point, we think the framework debate — Hydrogen vs. Next.js vs. everything else — is the wrong conversation. The framework is a delivery mechanism. What actually determines the quality of a headless storefront is the layer above it.
This post explains what that means in practice, and how we decide what to build on.
What the Storefront API Actually Gives You
Shopify's Storefront API is GraphQL and framework-agnostic. You can query products, collections, cart state, and customer data from React, Vue, Svelte, plain TypeScript, or whatever your team is comfortable in. Shopify says this explicitly, even if their documentation defaults to Hydrogen examples at every turn.
Hydrogen is one way to consume that API. It's React + Remix with Shopify-specific primitives baked in: cart hooks, product variant state management, Shopify Analytics integration. Oxygen, the edge-hosting layer, deploys globally across 285+ points of presence at no additional cost. For a team starting from scratch, on a pure Shopify backend, wanting a fast path to production — this is a genuinely good offer.
The thing to understand is what "headless" actually gets you beyond Hydrogen:
- Frontend and backend decoupled, so your CMS, search, PIM, and storefront can evolve independently
- Full control over rendering strategy (SSR, SSG, ISR, partial prerendering)
- Freedom to compose your stack from best-in-class tools rather than whatever Shopify supports natively
- The ability to serve commerce through non-Shopify surfaces — editorial pages, apps, kiosks, whatever
That capability doesn't require Hydrogen. It requires the Storefront API and a competent frontend team.
What Hydrogen Is Actually Optimised For
Hydrogen is a good fit when most of the following are true:
- Shopify is the only backend, and that's not changing
- The team wants Shopify-specific DX shortcuts (cart hooks, variant state, built-in analytics)
- Time-to-market is constrained
- Hosting simplicity matters (Oxygen removes the Vercel/Netlify/Cloudflare decision)
- The brand experience is commerce-first, not editorial-first
Hydrogen works. The question is when it's the right tool — not whether it's technically capable.
The Limitations Nobody Writes About
The honest account of Hydrogen's limitations gets buried, because most of the agencies writing about it have staked their practice on it. Here's what we've tracked:
Quarterly breaking changes, on a schedule
Hydrogen ties its versioning to Shopify's Storefront API calver cycle. The API updates every three months. When Shopify introduces breaking changes to the Storefront API or Customer Account API — and they do — Hydrogen components may need to be redesigned.
This isn't unique to Hydrogen — any headless implementation depends on the Storefront API. But Hydrogen's tight coupling means you're also absorbing Remix and Hydrogen-specific changes on top of API changes. Maintaining a Hydrogen storefront is not a "set and forget" proposition.
All-or-nothing frontend decoupling
This one surprises teams: with Hydrogen, you have to decouple the entire frontend. You can't lift a single page type — say, the product detail page — into a headless setup and leave the rest on Liquid. That kind of selective, progressive decoupling (which is often the sensible migration path for established brands) is only possible with other frameworks, where the Storefront API integrates alongside existing Liquid templates.
The app ecosystem gap
Many Shopify apps built for Liquid themes don't work with any headless setup — Hydrogen included. Reviews, wishlists, loyalty programs, gift cards, and bundle tools often need custom engineering rather than a plugin install. This applies to all headless implementations, not just Hydrogen, but it's worth stating plainly: the headless tax on app functionality is real and consistently underestimated in early project scopes.
The Custom Stack: What It Looks Like and When It Wins
The most common non-Hydrogen headless Shopify stack looks like this: Next.js on the frontend, Shopify Storefront API for commerce data, Sanity (or Storyblok or Contentful) as the headless CMS, deployed on Vercel or Cloudflare Workers.
The case for this stack over Hydrogen comes down to a few genuine advantages:
ISR and partial prerendering for large catalogs. Next.js's Incremental Static Regeneration lets you statically generate product pages and revalidate them on demand, which matters for catalogs with thousands of SKUs.
Composability across systems. When Shopify is one piece of a stack that includes a PIM, ERP, or second platform — a custom stack adapts better. Hydrogen's primitives assume Shopify is the authoritative source of truth on everything.
Independent CMS editorial control. For fashion and lifestyle brands, the editorial layer is often as important as the commerce layer. Structured content in Sanity, with custom field types and live preview, gives content teams a fundamentally different capability than Shopify's native metafields.
The Layer That Actually Matters
Here's the argument we keep coming back to: skilled developers can deliver a fast, well-structured storefront on either Hydrogen or a custom Next.js stack. The framework choice affects development efficiency and long-term maintenance burden. It doesn't determine product quality.
What determines product quality is the layer above the framework: how search works, how merchandising decisions get made, how the CMS data model is structured, how personalization and internationalisation are handled.
The brands that see meaningful outcomes from going headless aren't winning because they picked the right framework. They're winning because they rebuilt the commerce logic more deliberately than their previous monolithic setup allowed. The framework just removed the ceiling.
How We Actually Choose
When we evaluate a new headless Shopify build, the framework question comes late. The earlier questions are:
- Is Shopify the only backend, or is there a PIM, ERP, or second platform in the stack?
- How editorial-heavy is the brand? Is the CMS a publishing tool or a light product description layer?
- What's the realistic maintenance capacity? A lean in-house team may prefer Oxygen's zero-infrastructure model.
- Is there an existing tech ecosystem to integrate with, or a greenfield build?
- What's the migration path? Are there existing Liquid pages that need to stay live during the transition?
From there:
We'll recommend Hydrogen when: The brand is Shopify-native, DTC-focused, and wants a fast path to a performant storefront without managing infrastructure. The team is React/Remix-comfortable. The CMS needs are light.
We'll recommend a custom stack when: The brand has strong editorial identity, requires CMS-driven layout control, operates across multiple markets with complex pricing or localisation logic, or when Shopify sits alongside other backend systems.
The Question Worth Asking
Before any framework gets selected, it's worth asking what the team needs to maintain and what the brand needs to evolve.
Hydrogen is a well-funded framework backed by Shopify's engineering org. It will keep improving. Its quarterly release cycle is also its risk profile: staying current requires attention and, sometimes, meaningful refactoring.
A custom Next.js stack requires more initial scaffolding and a more deliberate hosting decision. It also gives you a longer runway before you hit the ceiling of what the framework was designed to support.
Neither is categorically better. The brands getting this wrong are the ones who made the framework choice first and the architecture decision second — who picked Hydrogen because it was the obvious answer, or picked Next.js because it's familiar, without working backward from what they actually needed to build and maintain.
The framework is not the product. What you build on top of it is.