Headless Ecommerce Is Easy to Explain. System Ownership Is the Hard Part.

A headless ecommerce diagram looks clean. A Next.js storefront on top. A commerce API underneath. Two boxes and one arrow.

Production rarely stays that tidy. Search arrives. Then a CMS, an ERP, a PIM, inventory rules, promotions, tax, analytics, and personalization. Every new box brings its own failure modes.

When I review these architectures, decoupling is rarely the hard part. Ownership is. The better question is not “should we go headless?” It is this: when we decouple the storefront, which responsibilities did we actually move, and who owns them now?

Headless Does Not Remove the Backend

Separating the storefront removes the theme layer. It does not remove the work the platform was doing. Checkout, pricing, inventory, customer accounts, orders, fulfillment, tax, promotions, and product data still exist. They need a clear home.

In a traditional setup, the commerce platform owns most of that by default. The theme calls platform code directly. When something breaks, there is usually one place to look.

After decoupling, the same responsibilities can spread across several systems and several teams. This is the diagram most proposals show:

Customer
↓
Next.js / React Storefront
↓
API Layer
├── Commerce
├── CMS
├── Search
├── ERP
└── Inventory

The diagram is easy. The questions it hides are not:

• Which system is authoritative for price and stock?
• Who owns the failure when one API is down?
• What happens when inventory sync is delayed?
• What happens when CMS content references a removed product?
• What happens when pricing differs by region?

If the team cannot answer these before the build, it will answer them during an incident.

Platform choice does not settle this either. Shopify’s Hydrogen is built on React Router and works with the Storefront API and Customer Account API. BigCommerce’s Catalyst is built with Next.js on its GraphQL Storefront API. Both give you a solid frontend starting point. Neither decides ownership for you.

Three Problems That All Get Called “Headless”

The request sounds identical every time: “we need headless.” The underlying problems are not identical. I try to separate them first. For the business side of that decision, see headless ecommerce vs traditional ecommerce.

1. A frontend problem

The store has a slow theme, heavy scripts, and a dated design. But the catalog is standard. Pricing is standard. Checkout works. There is one storefront and few integrations.

Here the constraint is frontend engineering. Clean up the theme, audit third-party code, fix images and caching. A new architecture would add a deployment pipeline and an API layer to solve a problem that better frontend work can solve.

2. An experience problem

Marketing needs buying guides, product education, campaign pages, and flexible layouts. Every idea has to fit theme templates, and every test needs a developer.

This is where separating presentation from commerce starts to pay off. Commerce keeps products, carts, and checkout. A CMS and a custom frontend own the experience. Each side can then change without forcing the other to move.

3. An architecture problem

The business has an ERP, a PIM, regional pricing, B2B rules, and fulfillment systems. Orders and stock move between tools. Middleware keeps growing.

This is bigger than a frontend decision. The storefront is one consumer of a wider system. The real work is deciding where pricing, inventory, and orders live and how those systems agree with each other.

Headless Is Not a Performance Strategy by Itself

A Next.js storefront can still be slow. I would not assume otherwise because the repo is modern.

Real storefronts collect analytics, tag managers, review widgets, personalization, and ad scripts. Slow APIs and uncached calls add latency. Oversized images and heavy client-side JavaScript add more. A decoupled frontend can carry all of that, and sometimes adds new network calls on top.

Performance depends on engineering: rendering strategy, caching, image delivery, API response times, and script discipline. Headless gives you control over those. It does not do the work for you.

Headless and Composable Solve Different Levels of Separation

Headless separates presentation from the commerce backend. That is one cut.

Composable architecture makes several cuts. Commerce, CMS, search, PIM, ERP, personalization, and analytics can each be a separate service with its own owner. You choose the best tool per capability and connect them through APIs.

That flexibility is real. So is the cost. Each additional cut adds integrations, monitoring, vendor relationships, and another place for data to drift. I treat headless as one decision and composable as a bigger one. They should not be bought together by default.

What a CMS Should and Should Not Own

Content is often the first thing teams separate, and for good reasons. Buying guides, landing pages, FAQs, campaign copy, and regional editorial content change often. Editors need previews and structure, not a deploy.

A well-planned headless CMS architecture gives that content a proper home. But the CMS should not quietly grow into a second commerce system.

Pricing, inventory, customers, checkout, and orders belong to commerce or to the operational systems behind it. When a CMS stores its own copy of a price or stock level, you now have two sources of truth. One of them will be wrong at the worst time.

The safer pattern is to store references. CMS content points to a product ID. The frontend fetches live commercial data from the commerce API and combines it with editorial content at render time.

Next.js supports this with on-demand revalidation by tag or path. A CMS webhook can trigger it when content changes. That keeps pages fresh without rebuilding everything. It also creates a dependency someone must monitor.

A Rough Decision Table

This is a starting point, not a rulebook.

Decoupled Technology, Undecoupled Responsibility

This is where distributed architecture turns into distributed confusion. The technology is separated. The responsibility is not.

Here is the pattern I look for in reviews. A price looks wrong on the storefront. Is it the commerce platform, the ERP sync, a regional price list, or a stale cache? If four teams each own a piece and nobody owns the path, the answer takes hours.

Or take inventory. The ERP is authoritative, but the commerce platform shows stock. A sync runs late. The storefront sells something that is gone. Who decides what customers see when the data is uncertain?

I want a written answer to a few things for every system in the stack:

• What is it the source of truth for?
• Who owns its uptime and its upgrades?
• What does the storefront show when it fails?
• How do we detect that it faile d?

None of this is exciting. All of it decides whether the architecture survives its second year.

When I Would Not Go Headless

I get cautious when:

• The store has standard requirements
• The existing platform handles checkout well
• One storefront is enough
• Integrations are limited
• The theme can support the experience the business needs
• No engineering team owns the extra infrastructure Sometimes keeping the monolith is good engineering. A simpler system with clear ownership beats a flexible one nobody can explain.

The Question I Start With

Headless gives teams real freedom over the frontend, the content, and the integrations. That freedom is valuable when a specific constraint justifies it.

So I start with one question. What is the current platform preventing us from doing cleanly? If the answer is a theme, fix the theme. If it is content freedom, separate content. If it is operations, look behind the storefront.

How have you decided where pricing and inventory live once the storefront was decoupled?