Headless has become a status decision rather than an architectural one. Somebody senior reads that a competitor went headless, and six months of budget disappears into rebuilding a storefront that was converting perfectly well in Liquid.
Sometimes it is genuinely right. More often the problem being solved was a slow theme, and a slow theme is far cheaper to fix than to replace. Here is the decision tree we actually use.
What headless actually changes
Going headless means Shopify keeps the products, orders, inventory and checkout, while the storefront your customers see is a separate application you build and host, talking to Shopify through its APIs.
You gain total control of the front end. You also inherit everything the theme layer was quietly doing for you: hosting, deploys, previews, and the ability of a marketer to change a banner without a developer. That last one is not a footnote. It is usually the cost that hurts most, six months in.
The four questions that decide it
Work through these honestly and the answer is usually obvious before you reach the end:
- Is there a front-end experience you genuinely cannot build in a theme? Not "would be nicer" — cannot.
- Do you have in-house developers who will still be here in two years to maintain it?
- Does your marketing team need to ship content without engineering time?
- Is the current problem actually performance — and have you tried fixing the theme first?
A "no" to the first two is close to decisive. A "yes" to the third pushes hard towards staying on Liquid or adopting a hybrid where content stays editable.
The performance argument, examined
Headless is usually sold on speed, and a well-built headless storefront is genuinely fast. So is a well-built Liquid theme. The stores that get dramatically faster after replatforming were rarely slow because of Liquid — they were slow because of twenty-six apps and a 2MB hero image.
Remove those and the theme is often within a few hundred milliseconds of what the rebuild would have delivered, for a fraction of the cost. Do the app audit and the speed work first. If you are still slow afterwards, you have a real architectural case rather than a hunch.
The costs nobody puts in the deck
Every app that relied on injecting into the theme now needs a bespoke integration or a replacement. Preview environments for marketing have to be built. Somebody owns hosting, monitoring and the on-call rota when the storefront goes down at 2am on Black Friday, and Shopify is no longer that somebody.
None of that is an argument against headless. It is an argument for costing it properly, because these items typically exceed the build itself over three years and they almost never appear in the pitch.
The middle path most teams should take first
The debate is usually framed as all-or-nothing, which is why it gets decided emotionally. In practice there is a middle option that solves most of the real problems without any of the ownership costs.
Keep the storefront in Liquid, and build only the genuinely custom piece — the configurator, the bespoke quoting flow, the one interactive tool your competitors do not have — as an embedded application that talks to Shopify. The catalogue, the cart, the checkout and the marketing pages stay in the theme, where marketers can operate them.
You take on the maintenance burden for one component rather than the entire front end. If that component turns out to be wrong, you delete it and the store is untouched — which is emphatically not true of a full replatform.
We reach for this far more often than we reach for full headless, and in three years nobody has come back asking for the rebuild they originally wanted. The custom thing shipped, the store kept working, and the marketing team never lost the ability to change a banner on a Friday afternoon.
Our default, and when we break it
Our default is Liquid, well built, with a performance budget and a theme a marketer can operate. It handles the overwhelming majority of DTC and mid-market stores comfortably.
And if you are being pushed towards it by a supplier rather than by a requirement, that is information in itself. The people who benefit most from a replatform are rarely the people paying for it.
The honest summary is that headless solves a problem most stores do not have, at a cost most stores underestimate. When it is right it is decisively right, and you will be able to say why in one sentence. When you cannot, the answer is almost always to fix the theme you already have.
One more framing that helps: ask what happens to this decision if traffic doubles, and what happens if the team halves. Headless survives the first comfortably and the second badly, while a well-built theme survives both. Most businesses are far more likely to lose an engineer than to double their traffic, and the architecture should reflect the likelier risk.
Be equally suspicious of the reverse pressure. Developers who have not worked in Liquid sometimes argue for headless because the theme layer feels unfamiliar rather than because it is limiting, and that is a preference dressed as a requirement. The honest test is whether you can name the specific thing the theme cannot do — if the answer takes more than a sentence, it is probably taste.
If you do go headless, decide the exit route while everybody is still optimistic. Who maintains this if the agency changes, or the one engineer who understands it leaves? A build nobody can safely modify is a build you will eventually rewrite, and that rewrite is far more expensive than the one you are contemplating now.
That question is not pessimism. It is the same diligence you would apply to any three-year commitment, and the projects that survive contact with reality are the ones where somebody asked it out loud before the budget was approved.
We break that default when the storefront genuinely is the product — configurators, complex personalisation, a large existing application the store must live inside — or when an in-house team already runs the same stack elsewhere. If you are weighing this up and want an unsentimental read, our Shopify development team will tell you when the answer is no. Get in touch.
