Headless Commerce in 2026: What It Costs, Who Abandoned It, and Where It's Going Next

Headless commerce costs you a frontend team, permanently. Not a project. A team, forever, because the thing you just took ownership of is the part of your store that changes every week.

That's the sentence that should be at the top of every headless pitch and never is. So let's do the version with the abandoned products, the GitHub numbers, and the honest case for doing it anyway.

What headless actually means, and the definition drift

Headless means your storefront is a separate application that talks to your commerce backend over an API. That's it. Your product data, cart, checkout and orders live in one system, and the thing customers look at is a different codebase you deploy independently.

The term has drifted badly. Vendors now call a theme with some API calls "headless-ready", and call a hosted frontend framework "headless" when it's tied to exactly one backend. Neither is wrong exactly. Both make the word useless for a buying decision.

The question that actually matters is narrower: can you replace your storefront without replacing your backend, and vice versa? If the answer to both is yes, you're headless. If either is no, you have a decoupled theme, which is fine and is not the same thing.

Headless is not the same as composable

Worth separating these because they get bundled and they carry different costs. Headless is about the frontend. Composable is about replacing your whole commerce backend with best-of-breed services. You can be headless on a monolithic backend, which is by far the most common and by far the most sensible configuration for a mid-market brand.

Who quit, and what that tells you

The most useful evidence in this category is not the case studies. It's the products that got killed.

Shogun Frontend

Shogun announced the retirement of Shogun Frontend on 23 March 2023, after three years of development and more than 50 live storefronts. Their stated reason: macroeconomic pressure making merchants cost-conscious, with downstream impact on their ability to deliver the vision for that product^[1]. They kept it running 9 to 12 months for migrations and redirected to Page Builder, which had over 35,000 active users^[1].

Read that ratio. 50 storefronts against 35,000 page builder users. Headless frontends are hard to sell and expensive to support, and a company with real distribution in the exact same customer base could not make the economics work.

Adobe PWA Studio

Adobe's PWA Studio was the recommended headless path for Magento and Adobe Commerce for years. As of 2024, Adobe is no longer actively developing it, with strategic focus shifted to Edge Delivery Services^[2].

Notice what that FAQ does and doesn't say. It states PWA Studio isn't actively developed, and it presents Edge Delivery Services as the direction, but it stops short of explicitly recommending against new PWA Studio projects^[2]. That's the shape of a product being quietly retired rather than sunset with a date, and it's arguably worse for merchants than a clean announcement, because there's no deadline forcing a decision.

Adobe's documented storefront direction now runs through Edge Delivery Services with Commerce drop-in components^[3].

Vue Storefront, now Alokai

Vue Storefront rebranded to Alokai, changed its licensing, and repositioned from an open-source storefront framework to a "Frontend as a Service" that sells hosting and orchestration^[4]. The main repository sits at roughly 10,900 stars and now carries no license field at all^[4].

That's not a failure. It's a company discovering that giving away the frontend and selling the platform is a better business than selling the frontend. Which is the same lesson Shogun learned, arrived at differently.

What we found: storefronts don't accumulate community, backends do

This is the analysis I'd point at if you only read one section.

We pulled the GitHub numbers on the major open-source commerce frontends and backends. Here's what they look like as of 22 July 2026.

Project	What it is	Stars	Licence
BigCommerce Catalyst	Storefront framework	242[5]	MIT
Shopify Hydrogen	Storefront framework	2,069[6]	MIT
Vue Storefront / Alokai	Storefront framework	10,937[4]	None declared
Vercel Commerce	Storefront template	14,171[7]	MIT
Medusa	Commerce backend	35,290[8]	MIT

Catalyst is the striking one. It's MIT-licensed, professionally built, heavily marketed by BigCommerce, and it has 242 stars^[5]. Hydrogen, backed by a company with millions of merchants, has 2,069^[6].

Medusa, a commerce backend, has 35,290^[8]. That's more than all four storefronts combined, several times over.

Why the gap exists

Stars are a rough proxy for developer intent to reuse. And developers don't reuse storefronts, because a storefront is the most bespoke thing a brand owns. Nobody's brand is a fork of somebody else's brand. Every serious build rewrites the components anyway.

Backends are the opposite. Nobody wants to write cart logic, tax rules, order state machines or promotion engines. Those are solved problems where reuse is the entire point.

Which means the "pick a storefront framework" decision that headless vendors spend all their marketing on is genuinely the less important of the two. Pick the backend carefully. The frontend framework is Next.js or it's Remix or it's Astro, and you'll rewrite the components regardless.

Worth noting what building a real backend costs, since Medusa's history is public: 21 commerce modules, roughly four years, over 10,000 commits, and $8 million of funding with a full-time team^[8]. If anyone tells you the backend is the easy part, that's the number to hold up.

Does headless actually make sense for you?

Five conditions. You want at least three before this is a good idea.

You have or will hire dedicated frontend engineers. Not an agency on retainer. People who own the codebase. This is the binding constraint and it's the one merchants underestimate.

Your storefront needs something the platform genuinely can't do. Not "faster", not "more modern". A specific interaction, a configurator, a multi-brand architecture, a content model your CMS owns.

You're serving multiple frontends from one catalogue. Web, app, kiosk, marketplace, partner sites. This is the strongest genuine case and it's the original reason headless exists.

Your content team is blocked by the theme. If marketing needs a developer for every landing page, headless plus a proper CMS fixes that. So does a page builder, for a lot less.

Performance is measurably costing you money and you've exhausted the cheap fixes. Image sizes, third-party scripts, app bloat. Do those first. They're free.

If you have one of those, don't. If you have three, it's a real conversation.

The costs nobody itemises

Here's the honest bill.

Build. A real headless storefront is 3 to 9 months. The 6-week demos you see are demos.

The apps you lose. This is the one that bites. Your platform's app ecosystem mostly injects scripts into a theme you no longer have. Reviews, upsells, popups, loyalty, live chat, cookie banners. Every one either has a headless SDK or it doesn't, and when it doesn't you rebuild it or drop it.

Go and count your installed apps before you cost a headless project. Genuinely count them. That list is your real migration scope.

Ongoing frontend ownership. Framework upgrades, dependency security patches, accessibility, browser bugs, someone on call. Your platform used to do this. Now you do.

Two deploy pipelines. Backend changes and frontend changes now ship separately and can disagree. You need contract discipline you didn't need before.

Preview and content workflow. Merchandisers used to see changes in the admin. Now they need a preview environment someone built and maintains.

Platform by platform

Shopify

Hydrogen plus Oxygen is the first-party path, MIT-licensed with 2,069 stars^[6], and the Storefront API is genuinely well-designed. Checkout stays on Shopify, which removes the single hardest and most dangerous part of a headless build.

That last point is underrated. You keep Shopify's checkout, its PCI scope, its fraud handling and its conversion optimisation, and you only own the browsing experience. That's the most defensible version of headless available anywhere. The Storefront API is what you build against, and it's worth reading the reference before scoping anything^[14].

The cost is the app ecosystem, which is Shopify's actual product. Going headless on Shopify means opting out of the thing that makes Shopify worth paying for. Plus API versioning: Shopify ships a new version quarterly with a minimum 12 months of support and at least nine months of overlap^[9], so you own an upgrade cadence forever.

WooCommerce

Woo has been headless-capable via the REST API and WPGraphQL for years, and this is genuinely the platform where headless is easiest to justify, because the default frontend is a WordPress theme and the ceiling on that is low.

The thing that catches people: WooCommerce's checkout is a WordPress page with hooks all over it, and a lot of payment gateway plugins assume that page exists. Headless Woo usually means either keeping the checkout on WordPress and doing headless browsing only, or rebuilding checkout against a payment provider directly.

The first option is boring and works. The second is where projects go wrong.

Magento and Adobe Commerce

The messiest position of the four. PWA Studio is no longer actively developed^[2], Edge Delivery Services with Commerce drop-in components is the documented direction^[3], and a lot of merchants built on PWA Studio in between.

Magento's GraphQL API is mature and complete, so a custom Next.js frontend against it is entirely viable and plenty of agencies do exactly that. It's just not the vendor-supported path any more, and you should price the support gap in.

If you're on Adobe Commerce today and considering headless, the honest question is whether you're going to follow Adobe's direction or diverge from it, and either answer is defensible as long as you make it deliberately.

BigCommerce

Catalyst is the first-party path, MIT-licensed and technically decent^[5]. BigCommerce has always positioned API-first more strongly than Shopify, and the API quality backs it up.

The 242-star count isn't a criticism of the code. It's a signal about ecosystem depth, and ecosystem depth is what you fall back on when something breaks at 11pm. Fewer people have hit your bug before.

Plan boundaries matter here too, with auto-upgrades at $30,000 and $100,000 trailing-twelve-month GMV and 0.9% overage above $33,333/month on Scale^[10].

Custom and self-hosted backends

Medusa, Saleor, Vendure, or your own. Maximum control, maximum ownership. Medusa's 35,290 stars and 21 modules make it the most credible open-source option^[8], and the trade is that you now own PCI scope, payment integration, tax logic and everything else a hosted platform was doing quietly.

The headless decision table

Your situation	Verdict	Do this instead
No dedicated frontend engineers	No	Theme work plus a page builder
Site feels slow	No, not yet	Audit third-party scripts and images first
Marketing blocked by developers	Maybe	Try a page builder or a CMS integration first
Multiple frontends, one catalogue	Yes	The original and strongest case
Configurator or unusual interaction	Yes	Consider headless for that route only
On Shopify, want to keep the apps	Partial	Headless browsing, native checkout
On Woo with a low theme ceiling	Yes	Keep checkout on WordPress at first
On Adobe Commerce, on PWA Studio	Decide deliberately	EDS or diverge, but choose[2]
Under £2M revenue	Almost certainly no	The team cost dominates everything

Where we think this goes next: agent-native storefronts

Here's a point of view rather than a product, and I want to be completely clear about that up front. Nothing in this section is built, shipped or available. It's a direction we're working toward and there is nothing to buy or join. If that changes we'll say so plainly.

Every headless storefront framework that exists was designed for a human with a browser. Hydrogen, Catalyst, PWA Studio, Alokai, all of them. They render pages, they handle clicks, they optimise Largest Contentful Paint. Then, over the last eighteen months, they've all bolted agent support on the side: structured data, feeds, an MCP endpoint, a protocol adapter.

That works. It's also obviously backwards if a meaningful share of your buyers turn out to be agents.

What changed underneath

Two specs landed in quick succession. Google's Universal Commerce Protocol launched at NRF on 11 January 2026 with Shopify, Etsy, Wayfair, Target and Walmart as co-developers, defining how agents discover and transact across the full shopping journey^[11]. Shopify's engineering team published their account of building it^[12]. And the Agentic Commerce Protocol, maintained by OpenAI and Stripe, is at spec version 2026-04-17 covering cart, feed, orders, authentication and checkout^[13].

Both assume the merchant exposes structured, queryable commerce data and a transactable checkout endpoint. Neither cares about your hero image.

The gap between that assumption and reality is large. Adobe Analytics reports product pages scoring worse on machine readability than homepages or category pages across US retail^[15], and an audit of 141 product pages across 29 retailers found 70% missing all three of the attributes an agent needs to transact, with 15% returning an HTTP 403 to agents outright^[16]. A headless rebuild is the cheapest moment you will ever have to fix that, because you are touching the rendering layer anyway.

The question we think is interesting

What does a storefront look like when it's designed for both audiences from the first line of code, rather than for humans with an agent adapter stapled on?

Some of what that implies is guessable. Product data that's structured first and rendered second, not scraped back out of HTML. One canonical answer to "is this available, at what price, delivered when, returnable until when", served identically to a browser and an agent. Merchandising rules that apply to both surfaces rather than only the visual one. And a checkout that can be completed by a token-bearing agent without the merchant losing merchant-of-record status.

Some of it isn't guessable at all. Nobody knows what agent-facing merchandising looks like, or whether it's even legitimate to rank differently for an agent than for a person. Nobody has solved dispute liability when an agent buys the wrong thing.

Where we sit, honestly

Sellarix is building toward an agent-native headless storefront running on our own commerce backend. That is a direction, not a release. It isn't available, it isn't in beta, and there's no waitlist. We've said publicly that our platform has no live customers yet, and it would be absurd to follow that with a storefront announcement.

What we will do is publish the thinking as it develops, including the parts that turn out to be wrong. That's worth more to you right now than a product page would be.

What to do this week

1. Count your installed apps and mark which have a headless SDK. That list is your real migration scope, and it's usually the thing that kills the project.
2. Run a performance audit before deciding anything. If third-party scripts are your problem, headless is an expensive way to avoid deleting them.
3. Answer the frontend team question honestly. Not "we could hire". Do you have them.
4. If you're on PWA Studio, book the decision meeting. Adobe stopped developing it in 2024 and there's no forcing deadline, which makes drift the default^[2].
5. Separate the frontend decision from the backend decision. The GitHub numbers say the backend is where the durable choice lives^[8].
6. Publish your structured product data properly, whatever you decide. It pays off on search, feeds and agents at once, and it's free.
7. Read the UCP and ACP specs. An hour each. They tell you what your storefront will be judged on^[11][13].

The takeaway

Shogun killed a headless frontend after three years and 50 storefronts^[1]. Adobe stopped developing theirs^[2]. Vue Storefront became a hosting company^[4]. BigCommerce's well-built, MIT-licensed, heavily-marketed storefront framework has 242 stars^[5].

That's not a case against headless. Plenty of brands run headless storefronts well and would never go back. It's a case against buying headless as a product, because the products keep dying and the ones that survive stop being products. What survives is the pattern, implemented by a team you employ.

So the real question isn't whether headless works. It's whether you want to own a frontend team for the next five years. Do you?

Sources

1. Sunsetting Shogun Frontend: What it Means for Stores. Shogun, 23 March 2023.
2. PWA Studio FAQ. Accessed 22 July 2026. Notes that Adobe is no longer actively developing PWA Studio as of 2024.
3. Adobe Commerce Storefront documentation. Adobe Experience League. Accessed 22 July 2026.
4. vuestorefront/vue-storefront. GitHub. Star count and licence status read 22 July 2026.
5. bigcommerce/catalyst. GitHub. Star count read 22 July 2026.
6. Shopify/hydrogen. GitHub. Star count read 22 July 2026.
7. vercel/commerce. GitHub. Star count read 22 July 2026.
8. medusajs/medusa. GitHub. Star and commit counts read 22 July 2026.
9. API versioning. Shopify developer documentation. Accessed 22 July 2026.
10. BigCommerce Pricing. BigCommerce. Accessed 22 July 2026.
11. Under the Hood: Universal Commerce Protocol (UCP). Google Developers Blog, January 2026.
12. Building the Universal Commerce Protocol. Shopify Engineering, 2026.
13. Agentic Commerce Protocol specification. Maintained by OpenAI and Stripe. Spec version 2026-04-17.
14. Storefront API reference. Shopify developer documentation. Accessed 22 July 2026.
15. AI traffic grows but retail sites lag in AI search visibility. Adobe Analytics, June 2026. Reported independently by Digital Commerce 360, 17 June 2026.
16. 70% Of Top Retailers Are Invisible To Agentic Commerce. Search Engine Journal, reporting the SALT.agency audit. 141 PDPs across 29 retailers.