What is Headless Ecommerce?

Headless commerce has been explained badly enough, often enough, that the term now carries more mystique than meaning. It is a straightforward architectural choice with real benefits and real costs, and the decision is usually clearer than the marketing around it suggests.

What it actually means

On a conventional ecommerce platform, the storefront and the commerce engine are one system. Shopify renders your pages from Liquid templates. BigCommerce renders them from Stencil. The platform owns the catalog, the cart, the checkout, and the HTML the customer sees.

Headless separates those. The platform keeps doing what it is good at — products, pricing, inventory, cart, orders, payments — and stops rendering pages. In its place you build a separate frontend application, usually in React with a framework like Next.js, which asks the platform for data over an API and renders the storefront itself.

The “head” is the storefront. Removing it leaves the commerce engine running without one, which is where the name comes from.

What you actually gain

Complete control of the frontend. No theme conventions, no template language limits, no waiting for the platform to support a rendering pattern. If you can build it on the web, you can build it in your storefront.

The ability to build things that aren’t pages. Product configurators, real-time availability logic, complex account portals, buying flows that behave like software rather than a catalog. This is where headless earns its cost most clearly.

One catalog, several frontends. A web storefront, a mobile app, in-store kiosks and a partner portal can all read from the same commerce backend without duplicating product data.

Independent deployment. Frontend changes ship without touching the commerce backend, which matters more on larger teams than it sounds.

What it actually costs

This is the half that tends to be underdescribed, so it’s worth being specific.

You now own a software application. Not a theme — an application, with dependencies that need upgrading, a build pipeline, infrastructure, and monitoring. The platform used to handle all of that. Now you do.

You rebuild things you already had. Server-side rendering, sitemap generation, canonical tags, structured data, redirect handling, image optimization, breadcrumbs, faceted search state in URLs. Every one of these came free with the platform’s storefront and now needs building and maintaining.

Apps stop working the way they did. Most storefront apps inject code into the platform’s theme. With no theme, they have nothing to inject into. Every storefront-facing app in your stack needs a headless equivalent, a custom implementation, or removal — and this frequently turns out to be the largest single piece of work in the project.

Ongoing development capacity becomes mandatory. A Liquid theme can sit untouched for two years and keep working. A Next.js application cannot: dependencies age, security patches accumulate, and frameworks move. Headless is a commitment to continuous maintenance, not a one-off build.

When it isn’t the answer

Worth saying plainly, because it is the more common case:

“We want more flexibility” is not a requirement. If you cannot name the specific thing the platform prevents you from doing, and say why it matters commercially, headless will cost you a great deal to gain something you have not yet identified.

Performance problems usually have a cheaper cause. Slow stores are most often slow because of accumulated third-party app scripts and unoptimized images. Both survive a replatform. Fix them first — if the store is fast afterwards, you have saved yourself a rebuild.

Design limitations are usually theme limitations. Modern Liquid and Stencil themes are far more capable than their reputation. A great deal of what gets scoped as “we need headless for this design” is achievable in a well-built conventional theme.

Small teams should be cautious. If one developer maintains everything, or you rely on an agency for occasional work, taking on a frontend application is a larger commitment than it appears on the day it launches.

The middle path most people actually want

The framing of “conventional versus headless” is misleading, because the most common real-world choice sits between them: keep your existing platform, and replace only the storefront.

Shopify supports this with its Storefront API and Hydrogen. BigCommerce supports it with a GraphQL Storefront API and Catalyst. You keep the admin your team knows, the checkout that already converts, the payment and tax configuration, and the operational tooling — and you gain frontend control where you actually needed it.

This is how most headless builds we work on are structured, and it is meaningfully lower risk than migrating to a headless-native commerce platform at the same time as rebuilding the storefront.

How to decide

One question does most of the work: what specifically can you not do today, and what is it worth?

If the answer is concrete — a configurator you cannot build, availability logic the platform won’t express, a buying flow that does not fit a product page, several frontends needing one catalog — headless is likely the right call, and the cost is worth planning for properly.

If the answer is general, the honest recommendation is to fix the specific problems you have on the platform you already run, and revisit this when a constraint has a name.

We build both, which is the only reason our answer to this question is worth anything. More on how we approach headless builds, or tell us what you’re running into and we’ll tell you which side of the line you’re on.