Few architecture decisions attract as much hype—or as much regret—as going headless. It arrives with an appealing story: total design freedom, blazing speed, a modern stack. What that story usually omits is the ongoing cost, the lost native functionality, and the team you now need to keep it all running.
Headless is a genuinely great answer to a specific set of problems. It is also a genuinely expensive answer to problems most stores do not have. The goal of this piece is not to talk you out of it or into it, but to give you a way to tell which situation you are actually in before you commit a year and a budget to finding out.
01 · Definitions
What "headless" actually means.
In a standard Shopify build, the storefront and the commerce engine are one system: Liquid templates render pages, and Shopify handles cart, checkout, and data together. Headless decouples them. Shopify remains the backend—catalog, cart, checkout, orders—while a separate front-end application, built on a framework of your choice, renders the storefront and talks to Shopify through the Storefront API.
That separation is the whole pitch and the whole problem. You gain complete control over the presentation layer and can build experiences a theme cannot. You also give up the tight, batteries-included integration that makes standard Shopify so productive—because now two systems have to be built, connected, and maintained where there used to be one.
02 · The upside
The real reasons to go headless.
There are legitimate, hard-to-fake reasons to decouple. When one of these is genuinely true, headless earns its complexity.
- An experience Liquid can't build — a highly interactive, app-like storefront, a complex configurator, or a design that fights the theme model at every turn.
- One backend, many front-ends — you need to serve the same commerce engine to a web store, a native app, kiosks, and content surfaces from a single source of truth.
- Deep integration with existing systems — a large content platform, a custom PIM, or an established front-end codebase the storefront must live inside.
- A team that can own it — you have, and can retain, front-end engineers who treat the storefront as a product, not a one-time project.
Notice what is not on this list: "we want it to be fast" and "we want it to look custom." You can have both on a well-built Liquid theme.
03 · The bill
The costs nobody puts in the quote.
Headless moves complexity, it does not delete it. Everything Shopify used to give you for free becomes your responsibility to build and maintain. That is the line item the exciting pitch leaves out.
You now own hosting, deployments, and the front-end's uptime. Many app integrations that "just work" on a theme need to be rebuilt against APIs or abandoned. The merchandising team may lose the visual theme editor, so simple content changes now route through developers. Every Shopify platform update that a theme absorbs automatically becomes a migration you schedule yourself. And the storefront needs ongoing engineering attention forever—headless is a product you maintain, not a project you finish.
Headless does not remove complexity. It relocates it from Shopify's servers to your payroll.
04 · The default
When Liquid and OS 2.0 win.
For the large majority of stores, a well-architected Liquid theme on Online Store 2.0 is the right answer, and it is not a compromise. Modern themes are fast when built with discipline, fully custom when designed with intent, and vastly cheaper to run because Shopify carries the infrastructure, checkout, updates, and the app ecosystem.
Crucially, most of what founders want from headless—speed, distinctiveness, a homepage that feels bespoke—comes from craft, not architecture. A slow, generic theme does not get fast and distinctive by going headless; it gets fast and distinctive by being rebuilt well. We have delivered stores that feel unmistakably custom and load in a fraction of a second entirely on Liquid, and they cost a fraction of a headless build to operate. Reaching for headless to fix a problem that is really a build-quality problem is the most common and most expensive mistake in this decision.
05 · The test
A framework you can answer honestly.
Run your situation through four questions, and answer them as they are, not as you wish they were. First: is there a specific experience you must build that Liquid genuinely cannot? Second: do you truly need one commerce backend feeding multiple front-ends? Third: can you fund and retain a front-end engineering capability indefinitely? Fourth: are you willing to give your merchandisers a more technical workflow?
If you cannot answer a clear yes to at least the first or second, headless is almost certainly the wrong tool—the other reasons rarely justify the cost alone. If you get a yes there but a no on three or four, you may want the capability but lack the team to sustain it, which is its own kind of warning. The framework's job is to separate "headless would be cool" from "headless is necessary," because only the second one is worth what it costs.
06 · The nuance
The middle path most people miss.
Headless is not a binary. Shopify's own Hydrogen and Oxygen make the decoupled path far more supported than the roll-your-own stacks that gave headless its reputation for pain, narrowing the maintenance gap considerably. And you can go partial: keep the store on a fast Liquid theme while building one highly interactive surface—a configurator, an immersive product experience—as a headless island where it actually earns the complexity.
That hybrid approach often delivers the ambition behind the headless request without betting the whole store on it. The discipline is the same one this framework is built around: match the architecture to the specific need, not to the trend. Decouple exactly as much as the problem demands, and no more. Then keep the storefront fast and the brand consistent, whichever side of the line you land on.
Quick check
Do you actually need headless?
- There is a specific experience Liquid genuinely cannot build.
- You truly need one backend serving multiple front-ends.
- You can fund a front-end team to own it indefinitely.
- Your goal isn't just speed or "custom"—those are build-quality, not architecture.
- You considered a hybrid island before going fully headless.
Choose the boring answer when it's the right one.
Going headless can be exactly right—for a store with a real reason and a team to match. For everyone else, a fast, distinctive, well-built Liquid theme delivers the ambition at a fraction of the cost and complexity, and keeps the merchandising team fast on their feet. Resist the trend, run the framework, and let the specific need decide. The most sophisticated architecture decision is often the one that refuses complexity it does not need.