A storefront architecture should make the required customer experience and daily operations practical to deliver. Start with the problem a standard Shopify theme cannot meet, the systems that must connect and the team who will look after the result.
A Hydrogen versus Next.js comparison also needs current terminology. Shopify’s present Hydrogen documentation describes Shopify storefront building blocks and integration with frameworks including Next.js. A decision based on the assumption that the two must be separate alternatives can miss that relationship. The cited Shopify guide covers Hydrogen 2026-10; check an existing store’s version before applying it.
Understand what each part owns
Hydrogen provides Shopify-specific building blocks for areas such as storefront data, carts and customer accounts. Your application still owns its interface, routes, content presentation and important operating decisions. Next.js provides the application framework; the Shopify integration and the rest of the stack must be designed around the requirements.
Current Shopify documentation shows a React Router starter deployed to Oxygen and a Next.js template deployed to Vercel. Confirm the versions, runtime and features for the chosen implementation. Avoid relying on a preview announcement or assuming every Shopify feature will appear automatically in a custom storefront.
| Decision | Question to answer |
|---|---|
| Customer experience | Which journey needs a custom storefront, and why? |
| Commerce | Which Shopify data, cart, account and checkout requirements must work? |
| Content | Who edits content, where is it stored and how is it reviewed? |
| Other systems | Which integrations and data owners are involved? |
| Operation | Who owns hosting, upgrades, incidents and releases? |
Check the theme option first
List the specific experience or workflow that the current theme cannot deliver. Then assess a focused theme change against the headless option. A custom storefront brings its own application, deployment and maintenance work; its value should come from a requirement the business cares about.
Review the apps and features the store relies on. Confirm how they work in the proposed storefront, what needs a custom integration and which responsibilities move to the development team. The plan and app subscriptions remain relevant even when the presentation layer changes.
Our Shopify design and development service covers both improvements to an existing theme and scoped builds. The Shopify Plus guide explains why the platform tier should follow the actual requirement.
Choose deployment from the required features
Use Shopify’s Hydrogen deployment guidance to check the runtime assumptions for your framework. Oxygen is an option for the documented React Router setup; the current documentation also covers a Next.js/Vercel path. Verify account eligibility, limits and any separate service charges before budgeting.
The official Next.js deployment guide covers Node.js servers, Docker, static export and adapters. Feature support depends on the deployment option; a static export has different capabilities from a server deployment. Confirm the required behaviour with the selected platform and adapter.
Include production and preview environments, domains, caching, logs, error handling and recovery in the operating plan. State who manages each part. A framework name alone does not establish hosting cost, security coverage or deployment portability.
Measure a representative customer journey
Compare a meaningful slice of the proposed experience before choosing a full build. Use representative products, content, media, fonts, apps and integrations. Record the device, network conditions, test method and what the customer needs to complete.
- Can a person find the relevant collection and product?
- Do product choices, pricing and availability remain clear?
- Does the cart behave correctly as the person changes their choices?
- Do search, account and localisation requirements work where they are needed?
- Can the team edit, review and publish the content it owns?
Evaluate loading, layout stability and interactions alongside correctness and accessibility. Keep a controlled lab result separate from field measurements and commercial outcomes. A different framework does not establish faster real-world performance or a conversion gain by itself.
Budget for delivery and ownership
Ask for a scope that covers discovery, design, integration work, data requirements, testing, launch checks and handover. Agree the dependencies and exclusions. There is no reliable project price or timeline based only on turnover or the framework name.
For ongoing costs, collect the actual proposed platform and hosting terms, third-party subscriptions, support coverage and development capacity. Record what the existing team can own and what needs an additional agreement. Keep forecast costs separate from verified current bills and avoid counting staff capacity as cash savings.
Agree how framework and dependency updates will be assessed, tested and released. Define the monitoring coverage, review arrangements and required approvals. Automated checks can help identify issues within that coverage; business decisions and sensitive changes still need the agreed human review.
Make the architecture decision reviewable
A useful decision record explains the requirement, options considered, evidence from a representative journey, dependencies, operating costs and named responsibilities. It should also show what remains uncertain and what would make the team reconsider.
Sonder can discuss a scoped Shopify build or improvement around those requirements. A headless build, substantial integration or a wider operating programme needs its own agreement. Snowball is ongoing Shopify work within agreed monthly capacity, priorities and timing; it does not automatically include a new storefront, every feature upgrade or unlimited support.
For a practical introduction to discovery, handover and ongoing work, see working with Sonder. The first decision is the useful work to investigate, followed by an appropriate architecture and a plan the team can run.
Sources and review
Substantively reviewed on 26 October 2026 against current primary documentation. Framework APIs, hosting arrangements and account terms can change. No performance benchmark, fixed budget or guaranteed business result is established here.