SEP 28, 2026 · UPDATED OCT 5, 2026 · 8 MIN READ
Headless in review: who actually needed it
The population of stores that needed headless got smaller over the past year, not bigger, because the platform closed the gap that used to justify most of the builds. Looking back, the group that was left is small.
In hindsight, a small and consistent group: stores sharing one front end across web and a native app, stores with a configurator or tool that had outgrown a theme section, and storefronts that were one surface inside a larger application rather than a site in their own right. Everyone else who went headless over the past year for page speed or theme flexibility was solving a problem the platform solved directly during the same period. Theme blocks and the Horizon foundation moved most of what used to be "the theme cannot do this" into settings a merchandiser can change. The stores that fared worst are the ones that committed to a full rebuild before checking whether that shift had already closed their gap.
IN SHORT
- The population of stores that need headless shrank over the past year, because theme blocks and the Horizon foundation gave merchandisers layout control that used to require a developer or a rebuild.
- The cases that held up in hindsight are narrow and specific: a shared front end across web and a native app, a configurator or tool that had outgrown a theme section, and a storefront that is one surface inside a larger application.
- The most common regret was not the build cost. It was discovering, months later, how many script-injected apps needed a bespoke replacement once there was no theme left to inject into.
- Partial headless (an island component inside a Liquid template) turned out to be the destination for most stores that considered a full rebuild, not a stepping stone to one.
- A full rebuild is expensive to reverse; a partial build is not, which is exactly why the partial builds are the ones people are still happy with a year later.
- Stores that went headless chasing page speed alone mostly stayed slow, because the apps and images causing the slowness followed them into the new front end.
- The test in hindsight is unchanged from the test going in: name the specific thing the theme could not do. Stores that could name it were satisfied with the outcome; stores that could not, were not.
The platform moved while the projects were being scoped
A headless proposal written at the start of a year and delivered at the end of it is being judged against a theme that no longer exists. That is the uncomfortable part of reviewing these projects: several of them were the right call when scoped and the wrong call by the time they shipped, because Shopify's own theme architecture closed part of the gap in the meantime.
Theme blocks (reusable, nestable layout components a merchandiser can rearrange without a developer) and the Horizon theme foundation both arrived through Shopify's 2025 Editions, moving a category of work that used to be "the theme cannot express this" into a setting someone without a developer can change. A rebuild scoped against the previous theme model was scoped against a smaller set of native capabilities than the one it eventually launched into.
This is not an argument against ever going headless. It is an argument for re-checking the premise right before committing budget, because the premise is the part most likely to have quietly stopped being true.
Who actually needed it, reviewed against outcomes
Three shapes of project held up. Reviewed a year later, each earned the cost for a reason that had nothing to do with speed or flexibility in the abstract. Each had a named, specific thing the theme could not do.
- One front end shared across a web storefront and a native app. Liquid renders web pages only, so a brand maintaining feature parity across a website and an app needed one API-driven front end regardless of anything else on this list. This case did not get weaker as the platform matured, because no theme update changes what a mobile app can render.
- A configurator or tool that had outgrown a theme section. Multi-step state, live pricing logic and a UI with its own navigation stop fitting inside a section once they pass a certain complexity, and no amount of block nesting turns a section into an application. The distinguishing feature of the projects that held up: the team could describe the exact interaction the theme could not do, not just that the theme "felt limiting".
- A storefront that is one surface inside a larger application. A portal, a marketplace, an account area with commerce bolted on: cases where Shopify supplies the commerce layer rather than being the site. These were rarely reconsidered, because the constraint was architectural from day one rather than a workaround for something the theme would eventually fix itself.
Reviewed a year later, each earned the cost for a reason that had nothing to do with speed or flexibility in the abstract.
The tell that it was the wrong call
The projects worth reviewing critically share a pattern, and it shows up in the same order every time.
It starts with a complaint that is really about something else (page speed, an unmaintainable theme, marketing waiting weeks for a landing page), each of which has a direct, reversible fix that costs a fraction of a rebuild. Stores that skipped straight to headless for one of these reasons mostly report the same result a year on: the site is still slow, because the apps and images that were the actual cause followed them into the new front end as equivalent JavaScript, or the publishing bottleneck reappeared because the new front end had no equivalent of a theme editor for marketing to use unsupervised.
The cost nobody itemized up front turned out to be the one that mattered most in review: every script-injected app (reviews, popups, personalization, most analytics) stopped working on cutover, and each one needed an API-based replacement, a custom integration, or a decision to go without. On more than one project this line item alone approached the cost of the rebuild itself, and it is the one estimate that is hardest to get right in advance because nobody audits their installed apps before scoping a front-end migration.
What held up, and what got quietly reversed
The clearest pattern in hindsight is architectural, not commercial: partial headless held up, and full rebuilds were where the regret concentrated.
An island (a JavaScript component inside a Liquid template, talking to the Storefront API for the one interaction the theme cannot express) keeps the theme editor, the site's cart, and every app that is not directly touching that one component. It is also trivially reversible: if the component turns out to be a mistake, it is a section deleted, not a migration. Stores that took this route for a configurator or a booking tool report the outcome they expected, because the blast radius of being wrong was always small.
A full front-end rebuild is a different kind of decision, because it is expensive to reverse. The stores now quietly running a second, parallel effort to rebuild what the theme already gave them (content editing for merchandisers, app equivalents for the ones that broke, structured data and canonicals re-emitted by hand) are almost always the ones that went all-in on a full rebuild for a reason that, on inspection, was one of the three reversible complaints rather than one of the three durable cases above.
What we would tell someone asking today
Ask for the same thing this time last year: the specific page or interaction the theme cannot express, named rather than gestured at. If the actual reason is page speed, theme debt or slow publishing, treat those as solved problems with their own direct fixes. Doubly so now, because theme blocks and the Horizon foundation removed a meaningful share of what used to make "the theme cannot do this" true.
If the answer is one of the three durable cases, build headless deliberately and, where possible, as an island rather than a full rebuild first. The projects worth pointing to a year later are the ones that could be undone if they turned out to be wrong, and mostly did not need to be.
Questions this raises
Did headless commerce turn out to be worth it this year?
For a narrow group, yes: stores sharing one front end across web and a native app, a configurator that had outgrown a theme section, and storefronts that are one surface inside a larger application. Stores that went headless for page speed or publishing speed alone mostly report the underlying problem is still there, because the apps and images causing it followed them into the new front end.
Did theme blocks reduce the need for headless commerce?
For a meaningful share of cases, yes. Theme blocks and the Horizon theme foundation gave merchandisers layout control that used to require a developer or a full rebuild, which is exactly the gap a lot of headless projects were originally scoped to close. Anyone re-scoping a headless build quoted before this should check what is now a setting instead.
What is the most common regret from a headless Shopify migration?
Underestimating the app replacement cost. Script-injected apps (reviews, popups, personalization, most analytics) stop working the moment there is no theme to inject into, and each needs an API-based replacement or a decision to live without it. On several projects this line item approached the size of the rebuild itself.
Is partial headless the safer bet in hindsight?
For most stores, yes. An island component inside a Liquid template keeps the theme editor, the site's cart and most installed apps, and it is reversible: a section deleted, not a migration undone. Full rebuilds concentrated most of the regret over the past year, generally because the original complaint turned out to be reversible on its own.
What signs show a headless build was the wrong call?
The site is still slow a year later because the apps and images that caused the slowness came along as equivalent JavaScript. Marketing still waits on a developer because the new front end has no equivalent of a theme editor. And a meaningful share of the budget is now going into rebuilding content editing, app replacements, or SEO signals the theme used to provide for free.
Who should still consider headless commerce today?
The same three cases as before, checked against the current theme rather than an old one: a shared front end across web and a native app, a tool or configurator that demonstrably cannot fit inside a theme section even with blocks, and a storefront that is one surface inside a larger application. Everyone else should re-test whether theme blocks or the Horizon foundation already closed the gap.
Read next
General information, not legal, tax or financial advice. Rates, limits and deadlines come from the vendors and authorities named, and they change: check the linked source before relying on one.
PART OF OUR SERVICE
Go headless when the storefront is the constraint, not before
Hydrogen, Oxygen, Storefront API and custom front ends
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritized list of fixes.
