← Articles · Architecture

Why Your Shopify Store Doesn't Need a Headless Frontend (Yet)

15 December 2025 · 4 min read

I wrote about headless commerce earlier this year. Since then, I've had a dozen conversations with brands considering a headless Shopify build, and in every case but one, my advice was the same: don't.

That's not because headless is bad technology. It's because the problems it solves aren't the problems most Shopify stores have.

The pitch versus the reality

The headless pitch goes something like this: decouple your frontend from Shopify, build a blazing-fast React application, achieve perfect Lighthouse scores, and deliver an experience that converts better than any theme-based store.

The reality: you spend £40,000 to £120,000 building a custom frontend. You then spend £2,000 to £5,000 a month maintaining it. Your marketing team can no longer make content changes without a developer. Half your Shopify apps stop working. And your Lighthouse scores, while technically better, don't move the revenue needle the way the proposal suggested.

I'm not exaggerating. I've done the post-implementation review on two headless Shopify builds that were rolled back to themes within eighteen months. In both cases, the performance gains were real but the operational cost was unsustainable.

What a good Shopify theme can do

Online Store 2.0 themes are significantly more capable than most people give them credit for. Sections everywhere, metafield-driven content, JSON templates, predictive search, dynamic product recommendations. You can build a highly customised, well-performing storefront entirely within the theme system.

Performance-wise, a well-optimised Shopify theme scores 70-85 on mobile Lighthouse. That's not perfect, but it's in the range where further gains have diminishing returns. The difference between a 75 and a 95 Lighthouse score doesn't produce a measurable conversion improvement for most stores. I've looked at the data across multiple brands. The correlation between extreme performance optimisation and revenue is weaker than the headless vendors suggest.

Where themes fall short is in genuinely interactive experiences — product configurators, complex bundle builders, real-time 3D rendering. For those specific features, a React component embedded within a theme section is a better approach than going fully headless.

Hydrogen: Shopify's own answer

Shopify's Hydrogen framework is their official headless solution, built on Remix and designed to work with the Storefront API. It's better than building a custom Next.js frontend from scratch because it handles many of the integration points — cart, checkout handoff, customer accounts — that custom headless builds struggle with.

But even Hydrogen requires a team comfortable with React, server-side rendering, and deploying to Shopify's Oxygen hosting (or your own infrastructure). It's a frontend application that needs building, testing, and maintaining separately from your Shopify backend.

If you have a frontend engineering team already, Hydrogen is a reasonable option. If you're hiring a freelancer to build it and then hoping it maintains itself, you're setting yourself up for problems.

The honest checklist

Go headless if:

  • You have a dedicated frontend engineering team (not just one contractor)
  • Your storefront requires interactivity that genuinely can't be achieved within a theme
  • You're running multiple brands or channels from a single Shopify backend that need radically different frontends
  • You've already optimised your theme-based store and hit its limits
  • You've budgeted for ongoing maintenance, not just the initial build

Stay on a theme if:

  • Your team doesn't include frontend engineers
  • Your customisation needs are primarily visual, not functional
  • You're planning to use third-party Shopify apps for major features
  • Your budget is better spent on marketing, product, or integrations
  • You haven't yet optimised your current theme for performance

The pragmatic approach

If you suspect you might need headless in the future, prepare for it without committing to it. Structure your data using metafields and metaobjects. Use the Storefront API for any custom JavaScript components. Build your integration layer to be frontend-agnostic.

This way, if you do eventually move to a headless frontend, your data model and backend integrations are ready. You've kept your options open without paying the headless tax today.

Most stores are better served by investing that £60,000 headless budget into better product photography, a solid PIM integration, email marketing optimisation, or conversion rate improvements on their existing theme. These deliver measurable returns. A headless rebuild delivers a better tech stack, which is only valuable if the tech stack was the bottleneck — and for most stores, it wasn't.

Need help with this?

If you're working on something related and could use an extra pair of hands, I'm available for project work. No obligation — just a conversation.

Get in touch →