The first question for a custom Shopify storefront is the customer requirement. The second is who will maintain the experience once it is live. A framework choice matters after those questions have a clear answer.
This guide covers Hydrogen 2026-10. Shopify's current documentation distinguishes it from Hydrogen 2026-04 and earlier. Record the installed version before discussing an existing store's upgrade path.
What the current toolkit does
Hydrogen provides Shopify commerce logic while a chosen framework handles routing, rendering and UI. Its framework-agnostic core works with web APIs. Shopify currently documents React and Vue bindings; frameworks without a packaged binding can use the core. Working starter templates include React Router and Next.js.
That makes Hydrogen and Next.js compatible choices rather than competing categories. The toolkit covers storefront and customer-account APIs; Shopify still supplies checkout. Your application retains responsibility for UI, SEO, account pages and its session-storage implementation.
These capabilities are not a measured speed improvement or a reason to replace a working store. For an architecture comparison, also read Hydrogen and Next.js: Shopify architecture choices.
Hosting follows the framework and runtime
Shopify's deployment guide maps its React Router starter to Oxygen and Vercel's Next.js template to Vercel. Other runtimes are possible when the framework supports them. A portable commerce toolkit does not make an application a drop-in deployment on every host.
The guide identifies production requirements including request-scoped state, server-only secrets, trusted buyer-IP handling, caching and production request handlers. A technical review should verify these against the actual build and target host rather than relying on a feature list.
Use a small proof before choosing a rebuild
Choose a journey that matters to the business and is difficult in the current store. Build enough of that journey to test the proposed approach. A polished home-page demo alone will not resolve catalogue, search, content or operational requirements.
- Write the requirement: describe what a shopper needs to do and why the existing approach falls short. Include the evidence rather than a preference for a new framework.
- Compare the simplest options: a targeted theme improvement, a supported app or a custom storefront. Estimate the work from the same requirements.
- Use representative content: actual product structures, images, fonts, filters and approved integrations. A fast empty demo does not represent a production store.
- Check the whole journey: product discovery, cart handover, redirects, metadata, accessibility, analytics and consent. Keep tests away from real customer data and payments until the required authority and safeguards are agreed.
- Measure on mobile: record the device, network, test method and loaded third-party scripts. Separate lab observations from field performance and commercial results.
- Record the decision: name the evidence that would support the rebuild, the unresolved dependencies and the person who approves the investment.
Make the ownership plan part of the proposal
Ask who owns the repository, hosting account, deployment process and documentation. Identify the people able to investigate an incident and review a change. Agree what the internal team can maintain and what requires external help.
A theme also has maintenance obligations: custom code, apps and content can introduce problems. A headless build has a different set of responsibilities across its frontend, dependencies and infrastructure. Neither architecture guarantees a healthy store or a particular maintenance cost.
Define the release process, rollback approach, accessibility checks, dependency reviews and monitoring coverage. A dashboard is useful only when its inputs and the response to an alert are understood. Monitoring cannot inspect inaccessible systems or guarantee an automatic repair.
Build the cost comparison from a scoped plan
Separate initial discovery and implementation from recurring hosting, software and maintenance. Obtain quotes for the actual integrations, content work, migration and support requirements. State currency, tax treatment, exclusions and the period being compared.
Keep confirmed expenditure separate from modelled staff time and possible additional revenue. This guide does not establish a typical enterprise build price or predict a return. A smaller, measurable improvement may be the right investment even when a custom storefront is technically possible.
The 12 Boards consolidation case records collection mapping, landing pages and redirects. Those requirements belong in a storefront proposal regardless of framework. It is not a Hydrogen benchmark or proof that a headless rebuild increased revenue.
Choose the work before the operating model
Shopify design and development starts with the store and the requirement. Ongoing Shopify support follows an agreed delivery plan. Headless engineering, bespoke integrations and wider marketing must be explicitly scoped; they are not assumed to fit a Shopify subscription.
Agree monthly capacity, timing, monitoring and approval boundaries before work starts. No framework or service plan guarantees instant self-healing, automatic leads or a release every week.
Sources and review
Reviewed 2 November 2026 against current Hydrogen 2026-10 documentation. Check the exact version and framework before applying this guide to an existing storefront.