Headless vs Liquid on Shopify gets argued as though it were a question about performance. It is really a question about who maintains the storefront and what you are willing to give up in exchange for control. Framed that way, most stores have a clear answer and it is not headless.
What you actually give up
This is the part that gets glossed over in the enthusiastic version of the pitch, and it is the part that decides most cases.
You give up the theme editor. On a Liquid store, merchandisers rearrange sections, swap images and change copy themselves. Headless, that becomes a developer task — or you rebuild an editing interface, which is a project of its own and one you now own forever.
You give up app blocks. A great deal of the Shopify app ecosystem works by injecting into the theme. Headless, many apps either do not work or need bespoke integration, and you will find this out one app at a time rather than all at once.
You give up a degree of checkout simplicity. Checkout stays with Shopify, which is correct, but the seam between your storefront and their checkout is now something you maintain across their releases.
And you take on hosting, deployment and monitoring for the storefront. That is a standing operational responsibility that the Liquid version does not have at all.
What you actually get
Real things, and worth having in the right circumstances.
Complete control of the front end: any framework, any rendering strategy, any interaction model. If your storefront needs to do something genuinely unusual — a configurator, a complex visualisation, an interface that is really an application — Liquid will fight you and headless will not.
One storefront over several back ends. If you are selling through Shopify alongside content or data from elsewhere, and it must feel like one product, headless is the honest way to build that.
And performance ceilings that are higher, though this is the most oversold benefit. A well-built Liquid theme is fast. A badly-built headless storefront is slow, and there are many of those, because the framework does not make performance automatic — it makes it your responsibility.
The three cases where it is right
The storefront is genuinely an application. Product configuration with real logic, tools customers use repeatedly before buying, interfaces with state. If the shopping experience is the product, you need the control.
Commerce is one part of a larger digital product. A platform with accounts, content and data where purchasing is one flow among several. Bolting that onto a theme produces something that always feels bolted on.
You have the team. Not "we can hire" — you have front-end engineers today who will still be there in two years. Headless without that is an asset nobody in the building can change, and we have been called in to rescue exactly that more than once.
The cases where it is sold and should not be
"Our site is slow." Almost always apps and images rather than Liquid. Fixing those is a fraction of the cost and usually gets you most of the way. Rebuilding headless to fix a speed problem caused by twenty apps will produce a headless store with twenty integrations and the same problem.
"We want a modern stack." A reason for the developer rather than the business. It is a legitimate consideration for hiring and retention, and it should be named as that rather than dressed up as a commercial case.
"Our competitors are headless." Some are, and some of those regret it. You cannot see the maintenance burden from the outside, which is exactly the part that decides whether it was a good idea.
The hiring question nobody asks first
A headless storefront changes who can work on your store, permanently. Liquid has a large pool of Shopify specialists who can pick up an unfamiliar theme and be useful the same week. A bespoke front end needs front-end engineers, and the ones who understand both the framework and commerce specifics are a much smaller group.
That matters most at the point you part company with whoever built it. Ask yourself honestly how quickly you could replace them, and what it would cost. If the honest answer is that you could not, the architecture has made a hiring decision on your behalf for the next several years.
The middle ground most stores should take first
Modern Liquid with sections, blocks and metafields is considerably more capable than its reputation. Most of what stores want headless for — bespoke layouts, custom product experiences, content-driven merchandising — can be built natively, keeping the theme editor and the app ecosystem.
The pragmatic sequence is to build properly in Liquid, find the specific thing it cannot do, and then decide whether that one thing justifies the rest. In our experience that question usually answers itself: either the blocker is real and obvious, or it turns out the frustration was with a theme rather than with the platform.
If you are weighing this seriously, the useful exercise is to write down the three things your storefront must do that you believe Liquid cannot. That list decides it, and it takes an afternoon. We will read the list and argue with it at no charge, including when the answer is that headless is right. How we build on the native side is described on the Shopify page.
