# Headless commerce in 2026: when it is worth it (and when it is not)

*By Roberto Lazar, founder of Dock30 · Published 2026-07-14 · Updated 2026-07-14 · 7 min read*

Most stores do not need headless commerce. When decoupling your storefront actually pays off, when it costs more than it returns, and how to decide.

Headless commerce means splitting your storefront, the pages shoppers actually see, from your commerce engine, the catalog, cart, checkout, and order logic, then wiring the two together through an API. It is worth it when you have real traffic, a design or omnichannel need that a themed platform genuinely cannot meet, and engineers who will own the frontend for years. For most stores it is **not** worth it. A well-built theme on Shopify or WooCommerce converts just as well, costs a fraction as much, and does not hand you a second codebase to maintain forever.

We have shipped ecommerce for founders and teams since 2021, and the headless question comes up in almost every discovery call now, usually because someone read that a big brand did it. So here is the honest version, including the parts the platform vendors leave out.

## What decoupling actually changes

On a traditional platform, the storefront and the commerce engine ship together. You pick a theme, you customize it inside the platform's rules, and the platform renders the pages. That coupling is the reason Shopify is fast to launch: most of the work is already done.

Headless breaks that link. The engine keeps doing catalog, cart, and checkout, and exposes it all through an API. You build the storefront separately, usually in Next.js or a framework like Shopify's Hydrogen, and call the engine when you need product data or a cart mutation. A product query looks roughly like this:

```graphql
query ProductByHandle($handle: String!) {
  product(handle: $handle) {
    title
    description
    variants(first: 20) {
      nodes {
        id
        price { amount currencyCode }
        availableForSale
      }
    }
  }
}
```

That is the whole trade in one snippet. You get total control over markup, rendering, and performance. You also now own every line of the frontend, including the parts a theme used to give you for free: search, filtering, cart drawer, checkout hand-off, accessibility, and the rendering strategy that keeps it fast.

## When headless is worth it

The market is real and growing. The headless commerce platform market was around [USD 2.04 billion in 2025 and is projected near USD 2.41 billion in 2026](https://www.mordorintelligence.com/industry-reports/headless-commerce-platform-market), a compound growth rate above 20 percent, and roughly [73 percent of businesses now run some form of headless architecture](https://www.swell.is/content/headless-commerce-statistics). Adoption is mainstream. That does not mean it is right for you, but it does mean the tooling has matured.

Headless earns its cost when at least one of these is true, and ideally two or three.

You have a frontend requirement a theme cannot deliver. A configurator, a heavily interactive product experience, content and commerce blended on the same pages, a design that fights the theme system at every turn. If your designer and your platform are in a constant argument, headless ends the argument.

You sell across more than one surface. Web, native app, in-store kiosk, marketplace, and increasingly AI shopping agents that read your catalog through an API. One commerce engine feeding several frontends is the case headless was built for. If everything lives on one website, that argument is weaker than it sounds.

Performance is a revenue line for you and the theme is capping it. Teams that go headless commonly report [load time reductions of 20 to 50 percent](https://www.swell.is/content/headless-commerce-statistics) because they finally control the scripts and the rendering. At high traffic, that difference is money.

You have engineers, in-house or on retainer, who will maintain the frontend for years. This is the one people skip. Headless is not a project you finish. It is a codebase you keep.

## When it is not, which is most of the time

If you run a store doing normal volume on a Shopify theme that converts fine, headless will almost certainly cost you more than it returns. You would trade a maintained, updated, secure storefront for one you now patch yourself, in exchange for performance gains your customers may never notice.

The uncomfortable detail: a headless build does not improve Core Web Vitals by default. A React storefront can fail Interaction to Next Paint as badly as any bloated theme, and in our audits the JS-heavy custom builds are often the worst offenders. We wrote a whole playbook on [fixing INP in Next.js and React](/blog/fix-inp-nextjs-react) precisely because "we went headless" and "we are fast" are not the same sentence. Speed is something you engineer and then monitor in the field, not something the architecture grants you.

There is also churn you inherit. Shopify's Hydrogen moved from Remix to React Router 7, and the [2026.4 release shipped breaking changes](https://weaverse.io/blogs/hydrogen-2026-4-breaking-changes-storefront-proxy-consent-mode) including a mandatory Storefront API proxy and the deprecation of the old remix-oxygen adapter. None of that is a crisis. It is simply the maintenance tax of owning a frontend, and it never stops arriving. A theme absorbs that work for you.

## The platforms, briefly

Four names cover most of what teams actually choose in 2026.

| Platform | Model | Best fit |
|---|---|---|
| Shopify Hydrogen | React framework on top of Shopify's engine | Brands already on Shopify who want a custom storefront without leaving it |
| Medusa | Open-source, self-hosted commerce engine | JavaScript teams who want full ownership and no license, and can run their own hosting |
| commercetools | Enterprise composable, API-first | Large retailers with a dedicated platform team and requirements to justify it |
| Saleor | Open-source, GraphQL-first, Python core | Teams comfortable with Python who want an API-native core |

Hydrogen is the smoothest path if you are already on Shopify. Medusa has become the fastest-growing open-source option and is credible well into eight figures of revenue, as long as you accept that you now run hosting, scaling, security, and upgrades yourself. commercetools is genuinely enterprise: powerful, and priced and staffed accordingly. Saleor suits Python shops that want an API-native core.

Choosing between them is a real engineering decision, which is most of the point. Themed platforms do not ask you to make it.

## What it really costs

The sticker price of a headless build is only the visible part. The frontend itself is a [custom development](/services/custom-development) project, and cost scales with catalog size, integrations, and how much of the storefront experience is bespoke. The larger number is what comes after launch: the engineers who keep it running.

Industry estimates make the point bluntly. On enterprise composable stacks, [year-one total cost of ownership often runs three to five times the platform license](https://www.askantech.com/shopify-hydrogen-vs-medusa-vs-saleor-2026/) once you add the frontend build, integration work, hosting, and ongoing engineering. That multiplier is not a headless-specific tax so much as an honest accounting of owning your own storefront. If you are comparing a headless build to a theme, compare the three-year cost, not the launch invoice.

Where headless does quietly pay back is the back office. Once your commerce engine is API-first, the internal tools sit naturally on top of it: order dashboards, inventory views, custom admin flows your team actually needs instead of the ones the platform shipped. That composable [dashboards and internal tools](/services/dashboards-tools) angle is often a better reason to decouple than the storefront itself, and it is the one teams underestimate.

## How we decide with clients

The first question we ask is never "which platform." It is "what can you not do today that is costing you money." If the answer is a specific frontend or omnichannel need, headless is on the table. If the answer is "I heard it is faster," we usually talk the client out of it and fix the theme instead, which is cheaper and faster and does the job. We would rather tell you that on a call than sell you a rebuild you did not need. If you are weighing the alternative directly, our take on [Shopify versus a custom build](/blog/shopify-vs-custom-ecommerce) and what a [custom site actually costs in 2026](/blog/custom-website-cost-2026) both go deeper on the money.

When headless is the right call, we scope it like any [ecommerce project](/services/websites-ecommerce): fixed price and a delivery date in writing before work starts, from EUR 350 for small scopes with real projects landing higher, plus 30 days of free support after launch. Every project we have delivered has landed on the agreed date, and there are hundreds of [public five-star reviews](/reviews) behind that.

If you are staring at the headless question and not sure which side of it you are on, grab a free 15-minute call at [calendly.com/dock30/15min](https://calendly.com/dock30/15min) or reach us through [contact](/contact). Bring your traffic numbers and your one frustration with the current setup, and I will tell you honestly whether you need a rebuild or a better theme.

## Frequently asked questions

**What is headless commerce?**

Headless commerce means separating your storefront (the pages shoppers see) from your commerce engine (catalog, cart, checkout, orders) and connecting the two through an API. You build the frontend yourself, usually in React or Next.js, and the platform handles the transactional back end. A traditional platform like a Shopify theme keeps both halves coupled, which is simpler but less flexible.

**Is headless commerce worth it for a small store?**

For most small and mid-size stores, no. A well-built theme on Shopify or WooCommerce converts just as well and costs far less to run. Headless starts to earn its keep when you have meaningful traffic, a design or omnichannel requirement a themed platform cannot meet, and engineers who will own the frontend for years.

**How much does a headless commerce build cost?**

A headless build is a custom software project, so the range is wide. The frontend alone often runs several thousand euros at the low end and well into five or six figures for large catalogs, and the real cost is the ongoing engineering to maintain it. Industry estimates put year-one total cost of ownership on enterprise composable stacks at three to five times the platform license alone.

**Does headless commerce improve SEO or Core Web Vitals?**

It can, because you control the markup, scripts, and rendering instead of inheriting a theme's. Teams report load time drops of 20 to 50 percent after going headless. But a headless build does not improve Core Web Vitals by default. A heavy React storefront can fail Interaction to Next Paint just as easily as any bloated theme if nobody watches the field data.

**What is the difference between headless and composable commerce?**

Headless is about the frontend: the storefront is decoupled from the commerce engine. Composable (often called MACH) goes further and lets you assemble the whole stack from separate best-of-breed services for catalog, search, payments, and content, each swappable through APIs. Every composable setup is headless, but not every headless store is fully composable.

---

Written by Roberto Lazar, founder of Dock30. Book a call: https://dock30.com/contact