Headless vs. theme: what D2C brands actually need.

What "headless" actually means

A Shopify theme, the Liquid-based setup most stores run, keeps the storefront and the backend in one system: Shopify renders the pages, handles the templating, and serves them, using themes and apps that plug directly into that layer. Headless decouples the two. The storefront becomes a separate application, most commonly built on Shopify's own Hydrogen framework using React, that talks to Shopify's backend, products, inventory, checkout, purely through APIs. Shopify still runs commerce; something else entirely renders what the shopper sees.

This is a genuinely different engineering model, not a theme with extra steps. A theme developer works inside Shopify's conventions and Liquid templating. A headless build is a full custom web application project that happens to source its data from Shopify, built and maintained the way any React application is.

The honest cost and complexity gap

The trade-off is not subtle, and glossing over it is where a lot of headless conversations go wrong. Headless typically costs 8 to 10 times more than a comparable theme build in the first year, and 5 to 8 times more on an ongoing basis. The driver isn't licensing, it's people: a theme project needs a Shopify theme developer, a widely available and comparatively affordable skill set. A headless project needs specialised React and Hydrogen developers who understand both frontend engineering and Shopify's API surface, a narrower, pricier pool, for both the build and every maintenance cycle after.

• Time to launch. A theme-based build, even a fairly custom one, commonly launches in 4 to 8 weeks. A headless build realistically runs longer, often measured in a few months rather than weeks, because there is no equivalent of a proven theme foundation to start from.
• Team required. A theme needs a Shopify developer, sometimes a designer. Headless needs frontend engineers comfortable with React and Hydrogen specifically, plus ongoing DevOps attention that a Shopify-hosted theme simply doesn't require.
• App compatibility. The vast majority of the Shopify App Store is built assuming a Liquid theme. Headless builds frequently need custom integration work to use apps that would just work out of the box on a theme, or need to rebuild that functionality from scratch.
• Editorial autonomy. A marketing or content team can usually edit a theme's sections and content directly through Shopify's admin. A headless storefront often routes content changes through a developer or a more complex CMS layer, depending on how it was built.
• Performance ceiling. Genuinely higher on headless, when done well. A custom frontend can be more surgically optimised than a theme carrying general-purpose flexibility it doesn't need for one specific store.

The theme case: why it's right for most D2C brands

For the large majority of D2C brands, especially those without an eight-figure revenue base and an in-house engineering team, Liquid is faster to market, cheaper to build, easier to maintain, and fully compatible with the app ecosystem the rest of the growth stack depends on, email/SMS, reviews, loyalty, subscriptions, analytics. None of that compatibility is guaranteed on a custom headless build; it has to be re-earned for every integration.

The performance argument for headless is also weaker in practice than it sounds in theory. A poorly built Hydrogen storefront will underperform a well-optimised Liquid theme, and Shopify's own performance data shows Liquid storefronts passing Core Web Vitals at higher rates than most headless implementations in the wild. That is not an argument against headless done properly, it is a warning against assuming the architecture itself guarantees speed. Most stores that feel slow are slow because of app bloat and unoptimised images, problems a headless rebuild does not automatically fix, and that a focused theme audit usually fixes faster and cheaper than a full replatform.

When headless is genuinely justified

The case for headless is real, it just applies to a narrower set of situations than the pitch usually implies.

• A theme is creating a measurable, specific limit. Not "it could theoretically be faster," but a documented performance or conversion problem tied directly to storefront architecture that theme-level optimisation has already failed to solve.
• The desired experience genuinely can't be built on a theme. Highly custom interactive product configurators, non-standard content and commerce blending, or regional storefront variation beyond what Shopify's native multi-store tools support.
• Revenue and scale justify the total cost of ownership. Shopify's own guidance points to roughly $50 crore (₹500 million) and up in annual revenue as the range where the Hydrogen conversation becomes a serious business decision rather than a nice-to-have; below that, the math rarely closes.
• There's a real, ongoing technical team to support it. Headless is not a one-time build cost, it's an ongoing engineering commitment. A brand without the team to maintain a custom frontend after launch is signing up for a maintenance burden it isn't staffed for.

If none of these apply, and the honest driver is "our theme looks generic" or "I want more creative freedom," that's a design and theme-customisation problem, not an architecture problem, and it is dramatically cheaper to solve as one.

The messy middle: what most brands actually need instead

Before jumping to headless, the higher-leverage move for most stores is exhausting what a well-built theme can actually do. That means auditing app bloat (see our CRO audit framework for where conversion typically leaks), optimising images and Core Web Vitals within the existing theme, and using Shopify's native performance and customisation tools before assuming they've hit a ceiling. Most stores that ask about headless have not yet done this work, and doing it first either solves the actual problem or, if it doesn't, gives a far more specific, evidence-based case for why headless is genuinely needed.

A decision scorecard

• Revenue base: comfortably above roughly ₹500 million a year, or well below it. Below, theme wins by default.
• In-house or retained engineering: a real team capable of maintaining a custom React frontend indefinitely, or none. No team, theme wins.
• The specific limitation: documented and theme-optimisation has already failed to solve it, or it's a general feeling of wanting "more." Documented and unsolved, headless case strengthens; a feeling, it doesn't.
• App dependency: heavy reliance on off-the-shelf Shopify apps for core operations, or minimal, custom-built functionality already. Heavy reliance favours theme; minimal reliance reduces headless's downside.
• Timeline pressure: need to launch or relaunch within 2 to 3 months, or flexible runway. Tight timeline favours theme decisively.

Where we land on this

We build and rebuild Shopify themes for a living, so it would be easy to assume this guide is just self-interested. It isn't: we'd rather tell a brand honestly that a theme solves their actual problem than sell a more expensive build that doesn't move the metric they care about. When a client's situation genuinely matches the headless criteria above, we say so. For the large majority who ask, the honest answer is that a clean, well-optimised theme gets them to the outcome faster, cheaper, and with less risk. Book a call and we'll tell you which case you're actually in.

FAQ