Headless Shopify
Hydrogen for ecommerce stores
Hydrogen is Shopify's React framework for building a storefront that reads the Storefront API and hands the shopper to Shopify's hosted checkout, deployed on Shopify's own hosting. It gives a brand complete control of the front end, and hands it complete responsibility for everything a theme used to provide. The first question we ask is not how to build it but whether the store needs it, because a headless build is a long term commitment to maintaining a front end.
Hydrogen
Headless Shopify · by Shopify. A text wordmark, not a logo: we are not affiliated with the vendor and make no claim to its trademarks.
What we do with it
The work inside Hydrogen
Testing the case before writing code
We look for the requirement a theme genuinely cannot meet: an interaction model, a configurator, a content and commerce merge, or a performance profile the current build cannot reach. If the honest answer is that a well-built theme would do, we say so, because the cost of headless is paid every month afterwards.
Data access and caching strategy
Product, collection and inventory data come from the Storefront API, and how those responses are cached decides both speed and correctness. Catalog pages tolerate caching well; anything showing stock, price or a customer's own information needs a shorter path. Deciding this early avoids a storefront that is fast and occasionally wrong.
A content model merchandisers can use
Without a theme editor, marketing needs somewhere to change a banner, reorder a homepage or launch a campaign page. We model that content in metaobjects and structured fields so it stays editable in the Shopify admin, rather than leaving every copy change dependent on a developer and a deployment.
Cart, checkout handoff and accounts
The cart is built in the storefront and the shopper moves to Shopify's checkout, so discounts, gift cards, subscriptions and account behaviour all need testing across that boundary. Customer account features are built against Shopify's account APIs, which is work a theme would have provided for free.
Tracking rebuilt on purpose
A custom front end fires no analytics or advertising events until someone implements them. We define the event schema first, implement it once in the application layer, and confirm each destination receives complete data, because this is where headless projects most often lose measurement without noticing.
When it fits
Hydrogen is the right tool when
Brands with an interaction the theme layer cannot deliver
Configurators, complex made-to-order flows and highly custom category experiences are real reasons to own the front end. Wanting a distinctive design usually is not, since themes can be built to a very high standard.
Sites where editorial and commerce are genuinely merged
When articles, guides and products need to share components and data, one application is easier to maintain than a marketing site pinned beside a store and stitched together with links.
Teams with engineering capacity to keep
Somebody has to apply dependency updates, fix regressions and add features. In-house developers or a retained partner is a precondition, not a nice addition.
What to watch
Where accounts drift
Facts about defaults and costs, not criticism. These are the settings we check on every account.
Storefront features are now yours to build
Search, filtering, quick add, upsells, review display, bundles and country selectors all arrive with a theme and have to be built and maintained here. Estimate the second year of that work, not just the launch.
Theme-based apps do not apply
Apps that install by adding blocks to a theme have nothing to attach to. What matters is whether each tool exposes an API you can integrate against, which is worth auditing against the current app list before committing.
Editability depends on what the build exposes
How much marketing can change without a developer is a design decision made during the project, and platform capabilities in this area continue to develop. Agree the editing model in writing before the build starts.
Cutover carries search risk
Replacing every template at once changes URLs, internal linking and markup simultaneously. A redirect map, structured data parity and a crawl comparison before and after are part of the launch plan rather than a follow-up task.
When is a headless build the right choice over a well-built theme?
When a specific requirement cannot be met on the theme layer and that requirement is worth ongoing engineering. Speed alone rarely justifies it, because most slow Shopify storefronts are slow due to apps and images rather than the theme architecture itself.
Does checkout stay on Shopify with a custom storefront?
Yes for most builds. The storefront hands the cart to Shopify's hosted checkout, which keeps payments, fraud handling, taxes and order creation on the platform. That boundary is what keeps a headless project scoped to the front end rather than to the whole commerce stack.
Will our existing Shopify apps still work?
Some will, some will not. Apps that operate in the admin or through webhooks generally continue to function. Anything that renders on the storefront needs an API and a custom implementation. We audit the app list at scoping, since replacing three apps changes the budget materially.
Is a custom storefront better for SEO?
It can be, because you control markup, rendering and internal linking completely. It can also be worse, because everything a theme handled correctly now depends on the team building it. The outcome follows the discipline of the build, not the technology choice.
What does support look like after launch?
Ongoing rather than occasional. Dependencies need updating, platform APIs are revised, and new campaigns need components. We plan for a monthly allocation of development time from the start, since a storefront left untouched for a year becomes expensive to change later.
Works alongside
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.