What breaks when you go headless on Shopify (and what it costs to fix)

The headless pitch is performance and control. Both are real. What rarely makes the pitch is that decoupling the storefront quietly breaks a set of things that worked the day before — and every one of them becomes a line item.

None of this is an argument against headless. It is an argument against finding out in week six.

Why things break at all

On a Liquid theme, apps work by injecting code into your theme. That is the contract: Shopify renders your storefront, and apps get to put things in it.

Headless removes the theme. Shopify is no longer rendering your storefront — your Next.js app is. There is no longer a place for an app to inject into.

Four categories, in the order they usually bite.

1. Theme-injected apps

Reviews, loyalty widgets, upsells, sticky bars, popups, size guides, back-in-stock. Whether each survives depends entirely on whether it has a usable API.

• Has a proper API — integrate it. A day or a few, per app.
• API exists but is thin — you get data but rebuild the UI. More work, and the UI is now yours to maintain.
• Theme-only, no API — replace it or drop it.

Count on somewhere between a handful and a couple of dozen apps on a mature store. A meaningful slice will need work.

2. Checkout

You do not rebuild Shopify's checkout, and you should not want to — it is the most optimised surface on the platform and it stays PCI-compliant without you thinking about it.

But your customer now moves from a storefront you fully control to a checkout hosted by Shopify. Three things need deliberate handling:

• Branding continuity — checkout customisation is real but bounded, and bounded in different ways depending on your plan.
• The handoff — cart state has to arrive intact, every time, including the awkward cases.
• Analytics across the seam — this is where attribution quietly breaks, and where nobody notices for a month.

3. Page builders and theme editing

If your team uses Shopify's theme editor, or a page builder like Shogun or PageFly, that stops.

This is the change that upsets people most, because it is the one they feel weekly. Somebody who could rearrange a homepage on a Tuesday afternoon now files a request.

It is fixable, and the fix is the project. A properly modelled CMS gives marketing more control than the theme editor did — genuinely composable sections, real preview, proper content types. But that is deliberate architecture work in week one, not something that emerges from a good build by accident.

When it is skipped, you get the worst outcome available: content hard-coded into components, and a marketing team that needs a deploy to change a headline.

4. Same-day changes

On a theme, a copy change is live in a minute. On a headless build it depends on how the build is architected — what is statically generated, what revalidates, how long caching holds.

Well built, this is invisible; content changes propagate in seconds and nobody thinks about it. Badly built, a price change takes a rebuild.

What this adds up to

Every row on the left is a decision somebody made early and deliberately. Every row on the right is the same decision skipped.

The question to ask

Before you sign anything, ask the agency to walk through your installed apps one by one and say what happens to each. It takes twenty minutes and it tells you two things: whether they have scoped your project, and whether the number in the proposal covers the project you actually have.

If you want us to do that pass, send your store URL and app list. We will tell you what survives, what does not, and what it adds — and if the answer is that a well-optimised theme keeps everything and costs a fraction, we will tell you that too.