This is an author defined decision rubric for a Shopify storefront. Its staffing, conversion, region, and app thresholds are planning heuristics from the original 2026 notes. Validate the requirements and ownership cost for your own store before using the score to choose a platform.
The five axis framework below includes the Liquid ownership comparison and dated cost assumptions. Shopify capabilities have changed since those notes, so the current documentation takes precedence for implementation details.
The fork: Hydrogen headless or Plus theme
The conversation usually starts with one of two pressures. Performance is failing, or the design team wants a storefront that feels less like a Shopify theme. Both pressures get framed as "we need to go headless," and the framing is wrong roughly four times out of five.
I score the brand on five axes before I'll recommend either path. Engineering team size. Conversion rate floor. Internationalization needs. App-dependency footprint. Surface count past the storefront. Each axis has a specific cutoff. Each cutoff comes from observed engagements at mid-market DTC operators in 2024 and 2025, not from a Shopify whitepaper.
Use the five axes to document the storefront decision and its assumptions. The ownership comparison covers platform responsibilities and the dated cost examples behind the rubric.
Axis 1: Engineering team size and shape
Cutoff: 2 dedicated frontend engineers minimum, with a third backend-leaning engineer available, before Hydrogen is defensible.
The Hydrogen ownership cost is roughly 1.5x to 2x a Plus theme team for the same surface area. You're now responsible for the HTML render path, the cart state, the checkout handoff, the SEO emissions, the schema markup, the sitemap generation, the canonical logic, the consent layer, the analytics layer, the third-party tag layer, the cache strategy at the edge, and every regression that ships when any of those move. A Plus theme inherits most of that for free.
The brands I see succeeding on Hydrogen all have at least two engineers who treat the storefront as their primary surface, not a side project. One engineer is not enough. Hydrogen builds with one engineer turn into hero engineering: the one person who knows the codebase becomes a single point of failure, and the brand's storefront velocity collapses the moment they go on PTO.
"Dedicated" matters here. A 0.4 of a full-stack engineer who also owns the data warehouse and the admin tooling is not a frontend engineer. They will get pulled to the next fire. A theme on Plus survives that staffing model because Shopify owns most of the platform surface. Hydrogen does not.
Where solo operators and agent-augmented stacks fit: I can ship a Hydrogen storefront solo with the agent-assisted Shopify development toolkit, but I would not recommend that staffing model for a brand that depends on the storefront for revenue. Solo plus agents is fine for a project. It is not fine as the steady-state ownership model for a $2-10M DTC store. The first time something breaks at 2am, the brand needs more than one human who can debug it.
Axis 2: Conversion rate floor and traffic stability
Cutoff: site CR consistently above 3.5% with no flat months in the last 12 months.
Hydrogen wins on perf when the perf delta moves revenue. For a brand sitting at 1.8% CR with a leaky funnel and broken event_id deduplication, the perf gain from Hydrogen is rounding error compared to the value of fixing the actual conversion mechanics. I have watched brands spend six months on a Hydrogen rebuild that gained them 200ms on LCP and lost them three months of merchandising velocity, and their CR was the same on launch day as it was the day they kicked off.
The brands where Hydrogen pays back on perf already have a strong baseline. CR over 3.5%, an average order value that justifies the engineering bill, and a measurement layer that can isolate the perf delta from everything else moving in parallel. If you can't measure the impact, you can't justify the cost.
The trap I see most often: "we'll go headless to fix our conversion rate." That is almost always a tracking problem, a PDP problem, or a checkout-friction problem. Going headless to fix CR is solving for the wrong axis. The diagnostic I run before any platform conversation is the Plus theme architecture pattern past 2M audit, which surfaces the actual CR levers in a few hours. If the levers are inside Liquid, Hydrogen does not open them up faster.
The traffic stability piece matters because Hydrogen's edge cache assumptions favor predictable load. If the brand spikes 20x on a launch and the team has not prewarmed the cache or scoped the edge functions correctly, the Hydrogen storefront degrades in ways a Plus theme on Shopify's CDN does not. This is fixable. It is also another piece of work the team owns now.
Axis 3: Internationalization and multi-region complexity
Cutoff: 3 or more regions with logic past what Shopify Markets handles natively.
Markets covers a lot. Region detection, currency, language, region-specific pricing within the standard model, region-specific catalogs through publication scoping, and region-specific shipping zones. For most international DTC brands at $2-10M, Markets is enough.
The threshold is when Markets visibly bends. Region-specific catalogs that need product-by-product pricing rules past Markets' percentage-based pricing. Shipping UX that needs region-specific carrier UI past what the checkout offers. Tax handling that needs custom logic past what Shopify Tax provides. Region-specific subscription rules that don't fit the subscription apps' region model. When three or more regions have requirements that bend Markets in different directions, the cost of stitching app-level overrides exceeds the cost of owning a Hydrogen storefront with explicit region routing.
Two regions on Markets is almost always cheaper than two regions on Hydrogen. Three regions starts to tip. Five regions with custom logic per region is a strong Hydrogen signal even if every other axis says no.
A separate marketing site may need live inventory, pricing, and variant data. Compare a shared commerce data layer with the cost of maintaining two independent integrations. Prototype the actual component and framework boundaries before assuming the same UI can run on every surface.
Axis 4: App-dependency footprint
Cutoff: under 6 critical Liquid-bound apps with no Hydrogen-equivalents available, or the migration cost is acceptable.
Most Plus stacks I open have 30 to 50 apps installed. Six to ten of them are critical. Reviews, subscriptions, cart upsell, post-purchase, loyalty, search, sometimes a personalization layer. A Hydrogen migration requires assessing every one of those for a Hydrogen-compatible alternative, and the assessment is not optional.
The audit I run on every brand considering Hydrogen: list every billed app, classify it as critical or non-critical, identify whether a Hydrogen-compatible package exists, estimate the migration cost per app, and total it. The estimate is rarely under $40K once you include data migration, integration testing, and the inevitable two or three apps that have no clean Hydrogen path.
The apps that consistently don't migrate cleanly are loyalty (where the data model is proprietary and the UI is theme-injected), niche shipping integrations (where the carrier widget assumes Liquid context), some personalization layers (where the JS-injected experiment framework assumes a theme), and any app that ships a Liquid section snippet rather than a clean API. The Shopify app stack decisions that age well covers which categories migrate cleanly and which don't.
The cutoff is honest: under six critical Liquid-bound apps, Hydrogen migration is a manageable workstream. Six to ten, the migration becomes the dominant cost line in the project. More than ten and the brand is paying for a partial Hydrogen storefront with Liquid-shaped holes patched in iframes, which is the worst of both architectures.
Axis 5: Surface count past the storefront
Cutoff: at least one non-Shopify surface in the next 12 months that needs to share storefront code.
A funded second surface can change the platform decision. For a React Native app, evaluate shared catalog and commerce rules separately from native UI implementation. A marketing site or partner widget that needs live product data can raise the same integration question. Test the real requirement before treating it as a headless trigger.
The vague-roadmap version of this trigger does not count. "We might build an app eventually" is not a surface trigger. "We have a six-month roadmap with a React Native app shipping in week 22 and the engineering team has signed off" is a trigger. The distinction matters because the cost of building Hydrogen against a hypothetical surface is the full Hydrogen cost, paid up front, against a benefit that may never arrive.
I have shipped a four-layout content theme build for a Plus brand where the design team initially assumed Hydrogen was required to support the variant flexibility. It wasn't. The variant flexibility came from the metafield-driven sections architecture and the metafield schema versioning pattern, both of which are Liquid-native. There was no second surface in the roadmap. Hydrogen would have added six months and roughly $200K to a build that landed in 11 weeks.
Scoring the rubric
One point per axis the brand passes. The cutoffs are deliberately strict; passing means clearly above the line, not "we're getting close."
4 to 5 points: Hydrogen is defensible. The engineering bill is justified by the surfaces, the team can carry the ownership cost, and the perf delta will move revenue. This describes maybe 10-15% of $2-10M DTC brands I've assessed.
2 to 3 points: it's a coin flip; default to Plus theme unless one axis is non-negotiable. Most brands land here. The instinct is to read the score as "we're halfway to Hydrogen," but that is the wrong read. Hydrogen costs are non-linear; halfway in costs more than fully in, and the brand pays the full Hydrogen tax for partial Hydrogen benefit. The right move is a Plus theme with a clean architecture, and a written commitment to re-score in 12 months.
0 to 1 points: a Plus theme is the right call. The conversation should pivot from "Hydrogen vs Liquid" to "is the existing theme architecture good?" If the theme is messy, the rebuild is a Plus theme rebuild, not a Hydrogen rebuild. The cost is one third the price and the risk is a fraction.
The 80% claim in the opening hook lands here. Across the engagements I've assessed in the last 18 months at $2-10M brands, roughly 4 in 5 score 0 to 3 points. That is the empirical case for "Hydrogen is the wrong call most of the time" at this revenue band. The rubric is the explanation.
“The cutoffs are strict on purpose. Halfway in costs more than fully in.”
When the rubric says no but the team still wants Hydrogen
This happens. The CTO read about Hydrogen at a conference. The design team has been pitched by an agency that ships Hydrogen. The founder saw a competitor go headless and noticed the launch announcement. The political pressure is real, and "the rubric says no" is not a complete answer when the team has already half-decided.
What I do in this scenario is write a one-page decision memo. Five axis scores. The two-year cost difference in dollars. The specific risk profile of each path. The agency or vendor pitch, addressed point by point. The memo gets signed by the CTO and the founder before any work starts. If the team still wants Hydrogen after reading the memo, fine. The memo is on file, and the engineering plan reflects the actual scope.
The decision memo has prevented at least three Hydrogen builds I would have walked into otherwise, where the team's pull toward headless was driven by something other than the rubric. In two of those cases, the underlying need (a perf problem, a design ceiling) was solvable inside a Plus theme rebuild at one-third the cost. In the third case, the brand realized they didn't need a rebuild at all; the existing theme just needed the theme architecture pattern past 2M cleanup work, which is a 4 to 8 week project, not a rebuild.
The honest fork when the team is split: keep the engineers, ship a thin Plus theme on a clean architecture, and revisit the rubric in 12 months with real data. Hydrogen is not a one-way door. If the rubric scores change because the brand grew, added regions, or shipped a real second surface, the Hydrogen migration from a clean Plus theme is faster than from a messy one. Investing in theme architecture quality pays back either way.
What I'd revisit, and with what evidence
The rubric is what I run today. A few things might shift the cutoffs in the next 12 months.
Hydrogen's surface-share story is winning faster than I expected. Brands with React Native apps or partner widgets are getting genuine value from shared component libraries, and Shopify has been investing in the developer experience for that pattern. If Hydrogen ships a cleaner shared-component story (specifically, easier code sharing with Expo apps), the surface-count cutoff might shift from "one real surface in 12 months" to "one real surface in 18 months."
The perf story is winning slower than the conventional wisdom claims, at least at the $2-5M band. Plus themes with careful theme code and disciplined third-party tag management are within rounding error of Hydrogen on Core Web Vitals for most retail page templates. The CR floor cutoff (3.5%) might tighten to 4% as Plus theme tooling improves, which would mean fewer brands clear it.
The engineering team cutoff might loosen if agent-augmented development matures further. Two engineers plus an agent stack can carry more than two engineers alone could a year ago. I am watching this carefully on my own builds; the empirical answer is not in yet.
The internationalization cutoff might tighten if Shopify Markets keeps expanding. Each Markets release covers more of the multi-region cases that used to require Hydrogen. The 3-region threshold could become 5 or more if Markets ships region-specific pricing rule support, which is the most common bend point I see today.
I will re-score the rubric publicly in 12 months and note which cutoffs shifted. The rubric is a snapshot of what works in 2026, not a permanent law.
Compare ownership before comparing frameworks
Liquid retains Shopify's theme rendering and editor conventions. Your team still owns its section code, content model, app choices, tracking, and the regressions those changes introduce. Hydrogen gives a headless storefront team more control over routing and UI, with a corresponding need to own the rendering, cache, accessibility, SEO, and integration behavior it ships.
Checkout is shared platform infrastructure in this comparison. Shopify's current Hydrogen documentation describes Shopify provided checkout alongside the Storefront and Customer Account APIs. Hydrogen does not supply its own checkout UI. Verify the capabilities and app integrations required by your plan rather than counting checkout as a benefit exclusive to Liquid.
The original January 2026 decision notes used Liquid build budgets of $15,000 to $60,000 and headless budgets of $80,000 to $250,000, with ongoing headless engineering estimated at $8,000 to $20,000 a month. Treat those as historical planning assumptions from that article. They are not current market benchmarks or a quote for your store. Estimate your actual migration, ongoing ownership, app replacements, and rollback path before comparing the two year cost.
The reference decision was a four layout Liquid content module with a shared metafield contract. It needed product specific media and copy, the existing reviews and subscription integrations, and a tracking contract. A second storefront surface was absent from that roadmap. That scope gave Liquid a concrete job it could do without adding headless ownership.
Reopen the decision when the requirements change. A funded mobile app, a marketing surface that needs live product data, region specific behavior that the current platform setup cannot support, or a content model requiring several systems can justify a new assessment. Code sharing still needs a prototype: browser components do not automatically become React Native UI.
Hydrogen itself has changed since the original notes. The documentation reviewed in October 2026 describes commerce primitives that work with supported server frameworks, including React Router and Next.js. Preserve the requirements and ownership comparison when revisiting this rubric, then check the current implementation path against the framework you intend to run.
Sources and specifics
- The 5-axis rubric reflects engagements at mid-market DTC operators in 2024 and 2025; cutoffs are derived from observed staffing levels, conversion data, app footprints, and roadmap conversations across 7 brands.
- The 2 dedicated frontend engineer threshold is the minimum staffing model I have seen carry a Hydrogen storefront at steady state without becoming a single point of failure.
- The 3.5% CR floor is the level at which the Hydrogen perf delta produces a measurable revenue signal in operator GA4 data; below that, the perf gain is rounding error compared to other CR levers.
- The 6-app cutoff for Liquid-bound dependencies reflects post-migration steady-state engineering costs observed across DTC stacks; above that line, the migration becomes the dominant cost in a Hydrogen project.
- Cost ranges for Hydrogen vs Plus theme builds (roughly 3-5x for Hydrogen on initial build and ongoing engineering) are consistent with the figures cited in the companion Hydrogen vs Liquid 2026 analysis.
- The rubric is a 2026 snapshot; the cutoffs may shift as Markets, Hydrogen tooling, and agent-augmented development continue to evolve.