Skip to content
Conversion is Powered by Oxify
Conversion
Book a call
Conversion
Book a free 30-minute call

30-minute call · No pitch · No commitment

HydrogenOxygenRemixHeadless Commerce

Shopify Hydrogen

The Shopify Hydrogen agency that tells you when not to go headless

Hydrogen and Oxygen storefronts with a content model your editors can actually use, caching that holds under load, and SEO parity treated as a build requirement with acceptance criteria.

  • React and Remix storefronts on Shopify's Storefront API
  • Shopify hosted checkout retained, including Shop Pay
  • An honest readiness assessment before any build is scoped
Book a Free Audit CallSee How It Works

Trusted by 50+ D2C brands · Google, Meta & Shopify partners

Google Partner — Premier 2024Meta Marketing PartnerShopify PartnerDash & DotReplenhairAllterOkhaiBanarsaiNOCDASMOKEDropshipwearwell
Headless, in plain terms

Headless is a trade, not an upgrade

Hydrogen is Shopify's React framework for custom storefronts, and Oxygen is the hosting that runs them. Together they make headless commerce substantially less risky than it used to be: you own the front end as an application, while Shopify remains the commerce engine and keeps the checkout, including the checkout extensibility surface on a Shopify Plus store. That combination is powerful, and it is also over-recommended. Going headless converts a managed problem into an owned one: rendering, caching, preview, redirects, structured data, and the merchandising workflow all become your responsibility. For a brand whose constraint is front-end capability, that is a fair trade. For a brand whose constraint is design, page speed, or conversion, a custom Liquid theme from our Shopify development team solves it at a fraction of the cost.

The most useful thing a Shopify Hydrogen agency can do at this stage is tell you which situation you are in. We build Hydrogen storefronts and we also talk brands out of them. When headless Shopify development is right, the work is a front-end engineering project with commerce constraints: a content model your editors can use, caching that holds up under traffic, Shopify SEO parity that survives the replatform or headless migration, app functionality rebuilt through custom Shopify app and API integration work, ERP and OMS connections shared with our Shopify Plus development practice, and a build your team can maintain after we hand it over. The case is strongest where interaction or content exceeds what a theme can express: configurators, quiz-driven discovery, large editorial libraries, and multi-brand groups sharing one component library.

When Hydrogen is the answer

And when it is an expensive way to not fix the problem

These are the situations that justify a headless storefront, alongside the ones that get mistaken for them.

  • A Liquid theme fighting the interaction you actually need

    Product configurators, deep filtering, real-time personalisation, or interfaces with substantial client-side state can be forced into Liquid, but the result is usually a large amount of JavaScript bolted onto a server-rendered theme. That is the clearest case for Hydrogen.

  • A content model the theme cannot hold

    Editorial brands, large content libraries, and campaign systems that need structured, reusable content often outgrow sections and metafields. A proper CMS with a front end that can consume it is a better answer than increasingly elaborate theme workarounds.

  • One commerce backend, several front ends

    When the same catalog and cart need to serve a web storefront, a native app, in-store displays, or a partner surface, an API-first architecture stops being an aesthetic preference and starts being the sensible structure.

  • Headless bought for the wrong reason

    A large share of headless projects are commissioned to fix page speed or conversion. Both are usually caused by third-party scripts, images, and app bloat, all of which follow you across the replatform. Headless does not fix them; it makes them more expensive to fix.

  • An inherited Hydrogen build nobody can maintain

    Hydrogen has moved fast. Storefronts built on earlier versions, or built by a team that has since moved on, can carry significant upgrade debt: outdated data fetching patterns, caching that was never tuned, and no tests. This is fixable, and it should be quoted after an audit.

  • Merchandisers locked out of their own storefront

    The most common post-launch complaint about headless is that the marketing team can no longer change a page without a developer. If the content model is not designed around how your team publishes, you have traded velocity for control and will feel it every week.

Capabilities

What we build with Hydrogen

A headless storefront is a front-end application with commerce constraints. These are the pieces that determine whether it is a good one, and what a full Hydrogen build hands over. Scope varies by engagement.

  • Hydrogen storefront development and Oxygen deployment

    React and Remix storefronts with a type-safe Shopify Storefront API integration and commerce-aware routing, cart, and product data patterns. Deployed on Oxygen, Shopify's own edge hosting, with preview environments per branch so stakeholders can review real work.

  • Content model and CMS integration

    Sanity, Contentful, Storyblok, Prismic, or Shopify metaobjects and metafields, with the CMS schema designed around your editorial workflow before any components are built. Editor documentation for the CMS is included.

  • Caching and performance architecture

    A route-level caching strategy per data source, image optimisation, and a third-party script budget. Measured on field data from real users.

  • SEO parity and headless migration

    A pre-change URL inventory and crawl, a redirect map built from that inventory, canonical tags, structured data, sitemaps, and pagination treated as build requirements with acceptance criteria, then post-launch indexation monitoring.

  • Internationalisation

    Multi-market routing, hreflang, currency and language handling, and locale-aware content, with the domain and URL strategy decided deliberately instead of inherited from a starter template.

  • App functionality replacement and integrations

    Reviews, search, subscriptions, loyalty, and personalisation rebuilt as API integrations where the storefront app previously relied on injected scripts. Analytics ships with a consistent event schema, and each integration has documented failure behaviour.

  • Design systems and component libraries

    A documented component library so the storefront stays coherent as it grows and new templates do not each become bespoke work.

  • Hybrid architecture

    Keeping Liquid for the bulk of the storefront and building only the demanding surface as a separate application. This is frequently the better trade, and far more reversible.

  • Hydrogen audits and rescues

    Technical review of an existing Hydrogen build covering version currency, data fetching, caching, test coverage, and deployment, with a prioritised remediation plan.

  • Testing, CI and handover

    Component and end-to-end tests, type safety, and a pipeline that runs them, because a front-end application without tests is a liability in a way a theme is not. Handover covers architecture decision records, technical documentation and a team walkthrough, a deployment and rollback runbook, and Hydrogen upgrade guidance.

Readiness call

What you get on the first call

Not sure whether you need headless at all? A short call is usually enough to tell.

Book a Strategy Call

  1. A straight answer on headless

    Whether headless is the right trade. If your constraint is design, speed, or conversion and not front-end capability, we will say so, and that is the cheaper answer.

  2. A read on your situation

    We look at the front-end requirement, the content model, the app stack, the team that will operate the result, and what is causing the problem you want solved.

  3. The hybrid option, if it fits

    Whether keeping Liquid and building only the demanding surface as a separate application would get you the capability with a smaller commitment.

  4. A scope that names its own unknowns

    If a build is right, a scope that says what is estimable and what needs an audit first, such as an inherited Hydrogen codebase.

Process

How a Hydrogen build runs

  1. Step 01

    Headless readiness assessment

    Before scoping a build, a straight answer to whether you need one. We look at the front-end requirement, the content model, the app stack, the team that will operate the result, and what is causing the problem you want solved.

  2. Step 02

    Architecture, content model and design

    Rendering and caching strategy, CMS selection and schema, routing and internationalisation, and the split between Shopify data and CMS data, with decisions recorded alongside their trade-offs. Interfaces are designed against real catalog data, including the awkward states: long titles, out of stock, deep variant matrices, empty search.

  3. Step 03

    Build and integration

    Two-week iterations with branch previews on Oxygen, code review, and tests, so stakeholders review working software at the end of each iteration. CMS, search, reviews, subscriptions, analytics, and any ERP or OMS connection are integrated with documented failure behaviour.

  4. Step 04

    Hardening and launch

    Caching tuned under realistic load, Core Web Vitals measured on field data, and a full SEO parity check against the pre-change URL inventory. Then a rehearsed cutover with a rollback path, redirect verification, and monitoring of indexation, vitals, and error rates in the following weeks.

  5. Step 05

    Post-launch ownership

    Hydrogen version upgrades, incremental feature work, and a conversion testing programme on real behavioural data. Headless storefronts need ongoing front-end attention, and we plan for it.

Hydrogen vs. Liquid

What you gain and what you take on

Both columns are real. The question is which set of trade-offs fits your team and your roadmap.

  • Front-end control

    Hydrogen (headless)
    Complete: it is your application
    Liquid theme
    Constrained by theme architecture

  • Merchandiser autonomy

    Hydrogen (headless)
    Depends entirely on the content model you build
    Liquid theme
    Theme editor out of the box

  • Checkout

    Hydrogen (headless)
    Shopify hosted checkout, retained
    Liquid theme
    Shopify hosted checkout

  • App compatibility

    Hydrogen (headless)
    Script-injecting apps need custom integration
    Liquid theme
    Broad compatibility

  • SEO responsibility

    Hydrogen (headless)
    Yours: canonicals, schema, sitemaps, redirects
    Liquid theme
    Largely handled by the theme

  • Performance ceiling

    Hydrogen (headless)
    Higher, with skilled engineering
    Liquid theme
    High, with a well-built theme

  • Typical build cost

    Hydrogen (headless)
    $80K to $300K
    Liquid theme
    $15K to $50K for a custom theme

  • Ongoing engineering need

    Hydrogen (headless)
    Continuous front-end ownership
    Liquid theme
    Periodic theme maintenance

  • Best suited to

    Hydrogen (headless)
    Front-end requirements Liquid cannot meet
    Liquid theme
    Almost everything else
Why Conversion

How we work

  • We will tell you not to go headless

    Most brands asking about Hydrogen do not need it. Saying so costs us a larger project and saves you a much larger mistake, and it is the single most useful thing we can offer at the enquiry stage.

  • Merchandiser experience is a build requirement

    The content model is designed around how your team publishes. A storefront your marketers avoid touching is a failed build regardless of its Lighthouse score.

  • SEO parity has acceptance criteria

    Redirect maps, canonicals, structured data, and indexation monitoring are scoped as requirements with pass conditions.

  • The hybrid option is on the table

    Keeping Liquid and building only the demanding surface as an application is frequently the better trade. We propose it when it is, even though it is the smaller project.

  • Performance measured on real users

    We use field data from actual visitors. Headless can be faster and can easily be slower, and the only way to know is to measure what those visitors experience.

  • Built to be handed over

    Tests, documentation, and architecture decision records, so your team or your next agency can own the codebase without reverse-engineering it.

Questions

Shopify Hydrogen, answered

What is Shopify Hydrogen?
Hydrogen is Shopify's React framework for building custom storefronts that talk to Shopify through the Storefront API instead of being rendered by Liquid. It ships with commerce-aware components, hooks, and caching conventions, and is built on Remix. Oxygen is Shopify's hosting for Hydrogen storefronts, included with Shopify plans, which removes the infrastructure question that used to make headless commerce a bigger commitment. Together they are Shopify's supported answer to headless: you keep Shopify as the commerce engine and checkout, and own the front end as an application.
Should we go headless with Hydrogen?
Usually not, and we would rather say that clearly than sell you a bigger project. Headless is a trade. It makes sense when your front-end requirement exceeds what Liquid can express: deeply custom interaction, a content model that has outgrown the theme, real-time personalisation, or a storefront that is one of several consumers of the same commerce data. It makes much less sense when the problem is design, merchandising, page speed, or conversion, because all of those are solvable in Liquid at a fraction of the cost and without giving up the theme editor.
What do we give up by going headless?
The theme editor, most immediately. Merchandisers who could previously rearrange a page themselves now file a ticket, and that change in operating model is the most commonly underestimated cost of a headless build. You also take on responsibility for rendering, caching, preview, redirects, structured data, and SEO behaviour that the theme handled for you. Many Shopify apps that inject storefront scripts will not work without custom integration. None of this is a reason to avoid Hydrogen, and all of it should be priced in before the decision.
How much does a Hydrogen build cost?
Market ranges run roughly $80,000 to $300,000, higher than a comparable Liquid theme build, because you are commissioning a front-end application. The variables that move it most are the content model and CMS integration, the number of templates and states that need designing and building, internationalisation, and how much of the existing app stack has to be rebuilt as native functionality. Ongoing cost is also higher: a Hydrogen storefront needs front-end engineering attention in a way a well-built theme does not.
How long does a Hydrogen build take?
Typically 16 to 24 weeks for a full storefront, longer with multi-market routing, a complex content model, or heavy personalisation. The front-end build itself is estimable. What extends timelines is usually the content model (deciding how pages are composed, where content lives, and how editors work with it) and the replacement of app functionality that previously came for free with the theme.
Does Hydrogen make my store faster?
It can, though it is not automatic and it is a poor reason on its own to go headless. Hydrogen gives you fine control over rendering and caching, which in skilled hands produces an extremely fast storefront. It also gives you enough control to build something slower than the Liquid theme you replaced, which happens more often than the pitch suggests. Most slow Shopify stores are slow because of third-party scripts, unoptimised images, and app bloat, all of which follow you to Hydrogen unless they are addressed directly.
Can we keep Shopify checkout with Hydrogen?
Yes, and you should. Hydrogen storefronts hand off to Shopify's hosted checkout, which means you keep Shop Pay, the full range of payment methods, fraud analysis, and on Plus the checkout extensibility surface. The storefront is custom; the checkout remains Shopify's. This is a significant part of why Hydrogen is a more conservative choice than fully custom headless builds against a third-party commerce API.
Can we use a CMS with Hydrogen?
Yes, and most Hydrogen builds do. Sanity, Contentful, Storyblok, Prismic, and Shopify's own metaobjects are all common. The decision matters more than the vendor: a content model designed around how your team publishes will make the build feel effortless, and one designed around a developer's mental model will produce a storefront editors avoid touching. We spend real time on this before writing components, because it is expensive to change later.
What about SEO on a Hydrogen storefront?
It is entirely achievable and entirely possible to get wrong. Hydrogen renders on the server, so content is available to crawlers, but you own the things the theme used to handle: canonical tags, structured data, sitemaps, redirects, pagination, hreflang, and metadata. On a replatform, the redirect map and URL parity work matters even more than usual because you are changing both the platform and the rendering layer at once. We treat SEO as a build requirement with acceptance criteria.
Can you take over an existing Hydrogen project?
Often, yes. We start with a technical audit: the version of Hydrogen and Remix in use, how data fetching and caching are structured, the state of the content model, test coverage, and the deployment setup. Hydrogen has evolved quickly, and a storefront built on an older version can carry meaningful upgrade work. We would rather quote that after looking than inherit it silently.
Do we need Shopify Plus to use Hydrogen?
No. Hydrogen and Oxygen are available across Shopify plans. Plus adds checkout extensibility, B2B, expansion stores, and higher API limits, which matter for a Hydrogen build in the same way they matter for a Liquid one, particularly the API limits if your storefront is data-hungry. The decision to go headless and the decision to upgrade to Plus are separate decisions and should be made separately.
What if we start headless and regret it?
Moving back to Liquid is a rebuild, which is why we push hard on the decision up front. A more reversible middle path exists and is often the right one: keep the Liquid theme for the bulk of the storefront and build only the demanding surface (a configurator, an interactive experience, a specific landing system) as a separate application. That gets you the capability without converting your whole storefront into a front-end engineering commitment.
Pairs well with Hydrogen

Explore related services

Hydrogen decisions rarely sit on their own. These are the areas they usually touch.

Book a call

Tell us what your front end needs to do

A 30-minute call, a straight answer on whether headless is the right trade, and a scope that names its own unknowns.

What happens next

  1. 1Pick a time for a 30-minute call.
  2. 2Tell us what your front end needs to do, and bring what you know about your content model, app stack, and the team that will operate the result.
  3. 3Get a straight answer on whether headless is the right trade, and a scope that names its own unknowns.

Prefer email? tarun@conversion.is