Headless commerce gets sold as the obvious upgrade — decouple the storefront from Shopify, render it yourself, and everything gets faster and more flexible. Sometimes that is true. Just as often, a team replaces a perfectly good Liquid theme with a Hydrogen build, inherits a deployment pipeline, a caching layer, and a CMS integration they did not have before, and ends up slower to ship than they were. The question is never whether headless is better in the abstract. It is whether the leverage is real for your store, and whether your team can carry the operational weight that comes attached to it. Those are two different questions, and a lot of headless regret comes from answering only the first.
What headless actually gives you
Going headless means the storefront is your code, fetching data from Shopify's Storefront API and rendering on your own infrastructure — Hydrogen on Oxygen, custom Remix, or Nuxt when the surrounding stack is Vue. The real wins are concrete: design freedom that Liquid's template model cannot express, Core Web Vitals scores a theme struggles to reach, and the ability to publish one product catalog across multiple surfaces — web, native app, kiosk, in-store screen — from a single source. Pick Hydrogen on Oxygen for the tightest Shopify alignment, custom Remix when you need more room than Hydrogen gives, and Nuxt when the team already lives in Vue. We choose per engagement, not per fashion.
One thing does not move: checkout stays on Shopify. That is non-negotiable for PCI compliance and the Shop Pay ecosystem, and it is also a feature, not a limitation — Shopify's checkout converts, and it is maintained by a team larger than your whole company. You can extend it with Functions and Checkout UI Extensions, but you do not rebuild it. Anyone proposing a fully custom checkout on Shopify is proposing a liability you will be paying down for years.
What it costs you
The cost is operational, and it is permanent. A Liquid theme is hosted, cached, and scaled by Shopify — you push code and it is live, and nobody gets paged for it. A headless storefront is an application you own: builds, deploys, preview environments, cache invalidation, error monitoring, and a CMS strategy for the content that used to live in theme settings. Merchandisers who could edit a section in the theme editor now need an interface someone has to build and maintain. Storefront-side apps you relied on — theme app extensions, embedded review and upsell widgets — often need rebuilding as native components. None of this is hard for a team that does it for a living, but it is real, ongoing work that did not exist before, and it does not stop after launch.
The honest decision matrix
We push toward headless when the store hits one of a short list of conditions, and we push back when it does not. The deciding factor is almost always whether a Liquid theme is actually blocking something the business needs — not whether headless sounds more modern.
- Go headless when design ambitions genuinely exceed what Liquid templates can express.
- Go headless when performance is commercial-grade and a tuned theme still cannot hit the targets.
- Go headless when you publish the same catalog across web, native, and physical surfaces.
- Stay on Liquid when the storefront is conventional and a well-built Online Store 2.0 theme does the job.
- Stay on Liquid when the team is small and cannot absorb a deployment and infrastructure layer.
- Stay on Liquid when the real problem is performance — most slow themes can be fixed without going headless at all.
The trap: headless as a performance fix
The most expensive mistake we see is treating headless as a way to fix a slow site. It can produce a fast site, but a slow Liquid theme is usually slow because of unoptimized images, render-blocking app scripts, and missing caching — and every one of those can be fixed in place for a fraction of the cost of a rebuild. We have moved Liquid themes from the 40s into the 90s on Lighthouse without going headless at all. Rebuilding the storefront to escape problems you could solve directly is paying for an architecture you did not need, and you will often discover the same oversized images and the same heavy third-party scripts dragging the new build down anyway, because they were never the platform's fault. Headless is an architecture decision; it is a poor performance tactic. If performance is the only complaint, fix the performance first and re-ask the headless question with clean data.
Headless storefronts should earn their complexity by shipping measurably better experiences. If you cannot name the measurement, you are not ready to go headless.
When we scope headless Shopify builds, the first phase is a decision, not a build — we audit the current theme, the performance budget, and the design goals, and we will recommend an Online Store 2.0 rebuild instead if that is the honest answer. Headless is the right call often enough to be a core service, and rarely enough that we say no to it regularly.