Shopify Hydrogen Is Being Rebuilt. Should You Build on It?

Owners ask us some version of the same question every few months: should we go headless on Shopify? This summer the honest answer got more complicated, because Shopify announced it is rebuilding the toolkit that answer depends on.

Here is what changed, what it means if you are weighing the decision right now, and the parts of it that have nothing to do with which framework wins.

What Shopify Hydrogen is

Hydrogen is Shopify's own way of building a custom storefront. Instead of running your shop on a Shopify theme, the templates your team edits inside the admin, you build the customer-facing site as a separate application. It pulls products, prices and carts from Shopify through an API.

So yes, Hydrogen is headless commerce with Shopify's name on it. The back half of your business stays exactly where it is: catalogue, orders, payments, and the hosted checkout your customers already trust. The front half becomes yours to build. And yours to maintain, which is the word owners tend to read past.

Hosting is not the obstacle. Shopify's hosting for these storefronts, Oxygen, is included at no extra charge on paid Shopify plans. It never was the expensive part.

What Shopify and Vercel announced, and what it changes

On 30 June 2026, Vercel and Shopify announced they are rebuilding Hydrogen from the ground up. Today's Hydrogen is tied to one specific React framework. The replacement is designed as a set of commerce building blocks that work with whichever frontend technology your team already uses.

That is a sensible direction. It is also, right now, a preview. Shopify's own documentation lists current Hydrogen as the fully supported path and the rebuilt stack as a developer preview aimed at new projects, the stage where APIs still move and nothing about the final shape is guaranteed.

Read that the way a buyer should. Nothing you have already built is about to break. But the supported way to build three years from now is probably not the supported way to build this quarter, and a storefront you commission today will live long enough to meet that migration. Price it in.

What it costs

Hosting is free, so the bill is people. Every element a theme hands you for nothing becomes something a developer builds and owns forever: product listings, filters, the cart drawer, search, the cookie banner, the account pages. Agencies publish headless price ranges, and those are sales material rather than research.

Our own rule of thumb, after cleaning up a few of these: whatever the build quote is, budget a comparable amount for the first twelve months of keeping the thing alive. That second number is the one that surprises people, and it does not disappear in year two. The same arithmetic we walked through for what headless commerce actually costs applies here, with Shopify's name on the invoice.

The speed argument, honestly

Speed is the usual reason to go headless, and speed genuinely pays. Google's study with Deloitte, which tracked 37 retail, travel and luxury brand sites across more than 30 million user sessions at the end of 2019, found that a 0.1 second improvement in mobile load time lifted retail conversion rates by 8.4%. The data is five years old. The direction has not changed.

What nobody can show you is credible evidence that headless Shopify storefronts are, in aggregate, faster than well-built Shopify themes. We went looking while researching this piece and it does not exist in public. What exists is single-brand case studies published by the companies selling the tooling, which tell you what one team achieved and nothing about what your team will.

Here is the part most owners miss: a React storefront built without discipline ships more code to the phone than the theme it replaced. Speed comes from the team, not the architecture. If your current store is slow, the cheapest fix is usually to make it fast, which is an engineering problem rather than a marketing one.

What you give up when you leave the theme

The theme editor goes away. That sounds minor until your marketing lead wants to move a banner before a promotion and finds the queue now runs through a developer. For plenty of teams that single change costs more in a year than the hosting they saved.

Your apps need auditing one by one. A large share of the Shopify app market installs by dropping blocks into your theme, and with no theme there is nothing to drop into. Some of those apps have a headless path, some have a workaround, and some you will be rebuilding, which is a line item people forget when they compare a headless quote against a straightforward Shopify build.

Multi-language and multi-country stop being a setting. Shopify's market configuration still exists, but the routing, the locale detection and the country selector become yours to build, and Shopify's own guidance warns that page caching and search engine crawlers make the naive approaches unreliable.

The good news deserves stating: checkout stays Shopify's. You are not rebuilding payments, and Shop Pay keeps working.

The maintenance bill nobody quotes you

Two clocks start ticking the day you go live.

Shopify releases a new API version every three months and supports each stable version for at least twelve. Miss the window and things stop working, on a schedule you do not control.

Your frontend framework runs its own calendar. The React framework current Hydrogen is built on has moved to a yearly major release and marked the previous generation end of life, which means no more security updates for anything still sitting on it.

Smaller changes carry hard dates too. When Shopify retired two of its tracking cookies, Hydrogen storefronts had until 30 April 2026 to upgrade or lose reliable attribution in their own analytics. A theme absorbs that class of change for you. A custom storefront sends you the ticket.

When Hydrogen is the right call

It is right when the storefront is a real product in its own right: a content-heavy brand site, several brands or regions served from one codebase, an interface that has to do something the theme model genuinely cannot. It is also right when you already employ frontend engineers, because then you are using capacity you pay for anyway.

It is wrong when speed is the entire reason. It is wrong when your team is small, because you are buying a permanent engineering dependency to solve a problem a theme rebuild solves for less. And it is wrong when nobody in the room can answer who fixes the storefront the week your developer leaves.

If you were already planning a Hydrogen build this quarter, start it. The current path is supported and the announcement does not change that. Keep the commerce logic thin and the framework-specific plumbing shallow, so the migration you will eventually do is a project rather than a rewrite.

Where Encomage fits

Most of the headless work that reaches us arrives as a rescue: a storefront built by a team that has since moved on, still working, quietly expensive to change. We tend to start by mapping what the store actually needs from its frontend before recommending anything, because on this particular decision the boring answer turns out to be right more often than the interesting one.