When headless is not the answer

Headless is not a mistake. It is a specific architecture that solves a specific set of problems very well, and it is sold to a far larger group of stores than the group that has those problems. The useful question is never "is headless good". It is whether this store's actual problem sits on the side of the boundary that going headless moves.

Most of the time it does not. The bill arrives anyway, in instalments, starting the first time marketing wants to trial an app.

What headless genuinely buys

Four things, and worth being precise about, because the sales material is not.

Rendering freedom. You own the render path end to end: framework, routing, caching, data fetching, interaction model. If the experience you need is closer to an application than to a set of pages, this is the one that matters, and nothing else gives it to you.

One front end over several back ends. If the storefront has to compose commerce with something that is not commerce — a large editorial system, a booking engine, a configurator with its own pricing logic — a custom front end stops being a preference and becomes the only shape that fits. A storefront whose primary content model lives elsewhere is fighting the templating layer on every page.

A front end that outlives the back end. Several commerce engines behind one experience, or a business that genuinely expects to change platforms. Rare, and real.

Interaction that refuses to be pages. Not "our design is custom" — every store's design is custom. Bespoke in the sense of a long configurator, a design tool, a marketplace-style experience where search is the primary navigation.

The reason most often given, and least often true, is performance. A theme is not slow because it is a theme. It is slow because it ships a stack of third-party scripts, an unoptimised hero image, fonts from three origins, and a section that loops the whole collection. Going headless removes none of those; it relocates them into a codebase where they are your problem instead of the platform's. Making a theme fast is performance work, at a fraction of the cost of an architecture change.

The bill nobody quotes

The checkout does not come with you

This is the load-bearing one. On Shopify, the checkout stays Shopify's. A headless storefront hands off to it, which means the stretch of the funnel with the highest revenue per pixel is the stretch you did not rebuild.

You now have a seam: your stack on one side, theirs on the other, meeting at the moment of payment. It is manageable — checkout extensibility customises what sits on the far side of it, and Functions change its logic — but notice what happened. The headless decision did not give you checkout control. It gave you control of everything except checkout, and checkout is where the money is. Most of what you can do over there requires Plus regardless of how the storefront is built.

The app ecosystem stops being install-and-go

Most Shopify apps ship a theme app extension: a block a merchant drops into a section and configures. That mechanism does not exist in your custom front end. Reviews, upsells, size guides, wishlists, loyalty widgets, back-in-stock, currency switchers — each becomes an integration project against whatever API the vendor exposes, if they expose one.

The effect is a change in who does the work. On a theme, a marketer installs an app on Tuesday and it is live by Wednesday. Headless, they file a ticket and wait for a sprint. Multiply by the tools a marketing team wants to trial in a year and you have converted an experimentation budget into an engineering backlog.

The theme editor goes away, and a workflow goes with it

This is the cost that surprises people six months in rather than on day one. The theme editor is the reason a merchandiser can build a campaign landing page on Thursday for a Friday launch without asking anyone: sections, blocks, per-template settings, live preview of an unpublished change.

Headless replaces that with something, usually a headless CMS — a good tool and a completely different workflow. Content modelled by a developer, edited in a system that does not know what the page looks like, previewed through a mechanism somebody has to build and keep working. Preview is the piece consistently underestimated: draft content, at the right URL, in the right locale, in a deployment that is not production, is a small project of its own and it rots the moment nobody owns it. Budget for it, or marketing will stop asking and route campaigns through paid landing pages instead.

Hosting, deploys and observability become yours

A theme is deployed onto infrastructure you never think about. Headless, you own it: a hosting bill, a CDN and cache strategy — including invalidation when a price changes — build pipelines, preview environments, error tracking, alerting, and a person whose phone rings. None of that is difficult. All of it is real, and it is operating cost rather than build cost. We build this kind of front end and enjoy it, so this is not a warning off the work. It is a warning against pricing a subscription as a project.

It also changes who can maintain the store. A theme storefront survives on a competent theme developer or an agency retainer. A headless one needs a front-end engineer with real framework experience and a deploy story that outlasts them.

The honest test

Four questions. The first two decide it; the last two tell you whether you can afford the answer.

1. Is the storefront's primary content model outside commerce? If the site is fundamentally a publication, a catalog of record, a booking flow, or a configurator that happens to sell at the end, headless is the shape that fits. If it is a store with pages, it is not.
2. Does the required interaction refuse to be pages? Ask what actually breaks if the experience is templates and sections. If the answer is "nothing, it would just be less elegant", the answer is no.
3. Can you name the person who owns the deploy pipeline in eighteen months? Not the agency — the accountability. If nobody, you are buying an architecture with no maintainer.
4. Have you exhausted the theme? Not "have you tried one" — has someone stripped the scripts, fixed the media, restructured content into metafields and metaobjects, and measured the result. If not, you are comparing a neglected build against a hypothetical one.

When a store answers no to the first two and reaches for headless anyway, the real driver is usually a bad experience with a theme somebody else wrote, a performance number with a simpler cause, or a preference for the stack the team already likes. The third is honest and deserves to be said out loud rather than dressed as an architectural argument. It is a hiring and morale decision, which is legitimate — just not the same conversation.

What to do instead, most of the time

Rebuild the theme properly, once, with the seriousness you were about to spend on the rewrite. Nearly every complaint that leads a merchant to headless is a complaint about a specific theme rather than about themes.

• Cut the third-party scripts. Count them, name an owner for each, delete the ones with no owner.
• Fix the media and the fonts. Correct sizes, correct formats, one origin, no layout shift.
• Model content in metafields and metaobjects rather than duplicated page HTML, so a change is one edit and a template renders it everywhere.
• Measure on real devices and real networks, before and after — not a score from a tool run once on a laptop.

A theme build done this way gives you a storefront the merchandising team can operate, apps install into, and that hands off to checkout with no seam. When a rebuilt theme loses a speed comparison to a headless build, it is almost never the templating layer that lost it.

The version of this argument that is not against headless

Go headless when the storefront is genuinely not a storefront: when commerce is one data source among several, when the interaction is an application, when the front end has to outlive the platform behind it. There the costs above are not costs — they are the price of the only architecture that works, and we build it happily. Much of what we do in React has exactly that shape.

Do not go headless to fix a slow page, to escape a theme you inherited, or because the front-end team would rather write React than Liquid. All three are fixable at a fraction of the price, and none of them is an architecture problem.