Headless commerce

Why it matters

Headless is the most consequential architecture decision a Shopify merchant can make, and the one most often made for the wrong reason. It is worth being blunt: most stores should not go headless. A well-built Liquid theme with the app list under control is faster, cheaper, and easier to staff than a custom frontend, and it keeps the merchandising team independent of developers.

The cases where headless earns its cost are specific. A storefront that has to serve content and commerce as one experience. A brand operating several markets from one codebase. A product configurator or booking flow that a theme genuinely cannot express. Design ambition that the section model keeps blunting.

Everything else — a slow site, a dated design, a checkout you want to change — has a cheaper answer inside the platform.

How it works on Shopify

The commerce engine stays where it is. Products, inventory, orders, discounts, and customers remain in Shopify; what changes is who renders the storefront. Your frontend queries the Storefront API over GraphQL and returns whatever HTML you like.

Two routes dominate. Hydrogen is Shopify's own React framework, deployed to Oxygen at no extra hosting cost, with commerce primitives already built. Or you build in Next.js or another framework and host it yourself, which trades those primitives for freedom of stack.

One boundary matters more than the rest: checkout stays Shopify's. You can hand off to it, and you can extend it through Checkout Extensibility, but you do not rebuild it. This is a feature — Shopify's checkout is the best-converting part of the platform — but teams expecting full control of the purchase flow discover it late.

Content is the other gap. Themes have the theme editor; a headless build has whatever CMS you chose, which is a decision to make on day one rather than month four.

Common mistakes

• Going headless for performance. Most slow Shopify stores are slow because of apps and images. Remove those first; if the site is fast afterwards, the architecture was never the problem.
• Underestimating what merchants lose. No theme editor, no app blocks, no drag-and-drop sections unless you build them. Every layout change becomes a ticket.
• Assuming apps still work. Most Shopify apps inject their functionality into the theme. On a headless storefront, review widgets, upsell tools, and popups need reimplementing or replacing.
• No plan for content. Landing pages, campaigns, and editorial need a CMS and an editing workflow, budgeted with the build rather than after it.
• Treating it as a project. A headless storefront is a system with ongoing maintenance, dependency upgrades, and on-call. Someone owns it after launch, permanently.

When you need help

Before the build, the useful outside work is the assessment: whether the requirement genuinely exceeds what a theme can do, and what the ongoing cost looks like over three years rather than at launch. An honest answer here is frequently "stay on Liquid", and that answer saves more money than any implementation.

If the decision is made, the parts worth not learning on the job are the Storefront API data layer, cart state, caching strategy, and the metaobject model behind editable content. Those choices are difficult to reverse once traffic is on them.