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 — not a launch-week checklist.
- React and Remix storefronts on Shopify's Storefront API
- Shopify hosted checkout retained, including Shop Pay
- Content model designed around how your team publishes
- An honest readiness assessment before any build is scoped
The honest version
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, but Shopify remains the commerce engine and keeps the checkout, which is the part that is hardest to rebuild and most expensive to get wrong.
That combination is genuinely 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 genuinely front-end capability, that is a fair trade. For a brand whose constraint is design, page speed, or conversion, it is an expensive way to not fix the problem.
The most useful thing an 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, and we would rather do the second than deliver a project that makes your team slower.
When Hydrogen is right, the work is a front-end engineering project with commerce constraints: a content model your editors can actually use, caching that holds up under traffic, SEO parity that survives the replatform, and a build your team can maintain after we hand it over.
When Hydrogen is the answer
And when it is an expensive way to not fix the problem
These are the situations that actually 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 genuine 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 just 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, but it should be quoted after an audit rather than assumed.
Merchandisers locked out of their own storefront
The most common post-launch complaint about headless is not technical. It 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.
Hydrogen storefront development
React and Remix storefronts on Shopify's Storefront API, with commerce-aware routing, cart, and product data patterns rather than a generic front end retrofitted to commerce.
Oxygen deployment
Deployment on Shopify's own edge hosting, with preview environments per branch so stakeholders can review real work rather than screenshots.
Content model and CMS integration
Sanity, Contentful, Storyblok, Prismic, or Shopify metaobjects — with the model designed around your editorial workflow before any components are built.
Caching and performance architecture
Deliberate caching strategy per route and per data source, image optimisation, and a third-party script budget. Measured on field data from real users rather than a lab score.
SEO parity and migration
URL inventory, redirect mapping, canonical and structured data implementation, sitemaps, pagination, and hreflang treated as build requirements with acceptance criteria.
Internationalisation
Multi-market routing, currency and language handling, and locale-aware content, with the domain and URL strategy decided deliberately rather than inherited from a starter template.
App functionality replacement
Reviews, search, subscriptions, loyalty, and personalisation rebuilt as API integrations where the storefront app previously relied on injected scripts.
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 genuinely demanding surface as a separate application — 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 and CI
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 and enablement
Documentation, architecture decision records, and walkthroughs so your team or your next agency can own the codebase without reverse-engineering it.
Process
How a Hydrogen build runs
Headless readiness assessment
Before scoping a build, an honest 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 actually causing the problem you want solved.
Architecture and content model
Rendering and caching strategy, CMS selection and schema, routing and internationalisation, and the split between Shopify data and CMS data. Decisions recorded with their trade-offs.
Design and prototyping
Interface design against real catalog data and real content, with the awkward states — long titles, out of stock, deep variant matrices, empty search — designed rather than discovered in QA.
Build
Two-week iterations with branch previews on Oxygen, code review, and tests. Stakeholders review working software at the end of each iteration.
Integration
CMS, search, reviews, subscriptions, analytics, and any ERP or OMS connection, each with documented failure behaviour rather than an assumed happy path.
Performance and SEO hardening
Caching tuned under realistic load, Core Web Vitals measured on field data, and a full SEO parity check against the pre-change URL inventory.
Launch
Rehearsed cutover with a rollback path, redirect verification, and deliberate monitoring of indexation, vitals, and error rates in the following weeks.
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; we plan for it rather than pretending otherwise.
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.
Sectors
Where headless tends to earn its cost
The case for Hydrogen is strongest where interaction or content genuinely exceeds what a theme can express.
Fashion and apparel
Editorial content alongside deep catalogs, lookbooks that need to shop, and merchandising that changes weekly. The content model usually matters more than the commerce layer here.
Beauty and personal care
Routine builders, shade and skin-type finders, and quiz-driven discovery — genuinely interactive surfaces that justify a front-end application.
Home and furniture
Configurators, room visualisation, material and finish selection, and freight logic. High AOV and long consideration cycles make richer interaction easier to justify commercially.
Electronics and technical products
Compatibility rules, deep specification comparison, and build-your-own flows. Usually a PIM integration problem before it is a front-end problem.
Food and beverage
Subscriptions, delivery windows, and regional availability. Worth checking whether the requirement is genuinely front-end or actually belongs in Functions and shipping logic.
Media and content-led commerce
Publishers selling product against a large editorial library — the clearest case for a real CMS and the front end to consume it.
Marketplaces and multi-vendor
Complex search and filtering, vendor-specific logic, and data from several sources composed into one experience.
B2B and wholesale
Account-specific catalogs, reorder flows, and quoting. Achievable headless, though B2B on Shopify covers much of it natively and is worth exhausting first.
Multi-brand groups
Several storefronts sharing a component library and content infrastructure, where the reuse argument for an application front end is strongest.
Deliverables
What you get
Scope varies by engagement. This is the shape of a full Hydrogen build.
Storefront application
- Hydrogen storefront on React and Remix
- Oxygen deployment with per-branch preview environments
- Documented component library
- Route-level caching strategy
- Component and end-to-end test coverage
- Type-safe Storefront API integration
Content and data
- CMS schema designed around your editorial workflow
- Shopify metaobject and metafield model
- Search, reviews, and subscription integrations
- Analytics and consistent event schema
- Documented failure behaviour for each integration
SEO and migration
- Pre-change URL inventory and crawl
- Redirect map built from the inventory
- Canonical tags, structured data, sitemaps, pagination
- Hreflang and multi-market routing
- Post-launch indexation monitoring
Handover
- Architecture decision records
- Technical documentation and team walkthrough
- Editor documentation for the CMS
- Deployment and rollback runbook
- Hydrogen upgrade guidance
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 actually 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, not as a launch-week checklist.
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
Field data, not a lab score from a developer's laptop. Headless can be faster and can easily be slower; the only way to know is to measure what actual 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?
Should we go headless with Hydrogen?
What do we give up by going headless?
How much does a Hydrogen build cost?
How long does a Hydrogen build take?
Does Hydrogen make my store faster?
Can we keep Shopify checkout with Hydrogen?
Can we use a CMS with Hydrogen?
What about SEO on a Hydrogen storefront?
Can you take over an existing Hydrogen project?
Do we need Shopify Plus to use Hydrogen?
What if we start headless and regret it?
Related
Explore related services
Hydrogen decisions rarely sit on their own. These are the areas they usually touch.
Shopify Plus Development
Checkout extensibility, Functions, B2B, and ERP integration on Plus.
ExploreShopify Development Agency
Custom Liquid theme and app development across every Shopify plan.
ExploreShopify App Development
Custom apps against the Admin and Storefront APIs.
ExploreShopify Migration Agency
Replatforming without losing search equity.
ExploreShopify CRO Agency
Testing programmes that tell you whether the rebuild worked.
ExploreShopify SEO Agency
Organic growth engineering for Shopify storefronts.
Explore