DEV Community: Nathan Allen

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

Nathan Allen — Mon, 12 Oct 2026 09:08:41 +0000

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?

I Like Strapi for Ecommerce. I Still Wouldn't Start With Strapi.

Nathan Allen — Thu, 08 Oct 2026 10:17:55 +0000

I wouldn't start with Strapi.

I wouldn't start with Sanity, Payload, or any other CMS either. The first decision in an ecommerce stack isn't the CMS. It's simpler than that. Which system owns each piece of data?

Teams skip that question because choosing a tool feels like progress. Content types get modeled. Pages get built. Then two systems quietly start storing the same price.

Ownership Comes Before the Tool

Before I look at any CMS, I list what the business actually stores. Products and variants. Prices and promotions. Inventory. Cart, checkout, and orders. Editorial content. Search indexes. Customer data. Anything the ERP or PIM already holds.

Then I ask three questions about each item. Who writes it? Who reads it? What should the storefront do when the owner is down?

The last question matters most. It's easy to say "the commerce backend owns prices." It's harder to decide what the page shows when that backend times out.

What Overlapping Ownership Looks Like

*Here's a stack I'd call reasonable:
*
Storefront (Next.js)
├─ Strapi → editorial content
├─ Medusa → products, prices, carts, orders
├─ ERP → warehouse stock
└─ Search → indexed catalog

Each box has one job. Strapi holds guides, campaigns, and FAQs. Medusa runs commerce. The ERP owns stock. Search owns discovery.

Now add one shortcut. A marketer wants a sale price inside a campaign banner. Someone adds a price field to the Strapi content type. Both Strapi and Medusa can now hold an editable price.

That's where the trouble starts. A sync job gets written. It runs late, or it fails quietly. Say the banner shows 49 and the cart shows 59. No CMS feature fixes that. It's an ownership bug.

The Architecture Mistake I See Most Often

The mistake is modeling content before deciding ownership. It feels harmless. A "Product Highlight" type with name, price, stock status, and image looks useful on day one.

Later, those fields drift. Names change in the commerce backend. Stock changes in the ERP. Editors fix what they can see, and nobody trusts the data anymore.

Now I write a one-page ownership table first. Every field gets one owner. If the CMS doesn't own a field, it doesn't get a copy of it. It gets a reference.

Store References, Not Copies

A reference is usually a product handle or ID. The CMS stores which product, not what the product is.

`// Editorial content comes from Strapi
const campaign = await strapi.getCampaign(slug);

// Product facts come from the commerce backend
const products = await commerce.getProducts(campaign.productHandles);`

This keeps one source of truth. But it has a cost. Every campaign page now needs two requests. Previews need commerce data too. If the commerce API is slow, the campaign page is slow.

So I decide the failure behavior up front. If products don't load, the page should still show the editorial content. The product block can hide or fall back. A buying guide shouldn't return a 500 because a price service had a bad minute.

I'd rather accept two requests than maintain two prices. But it's a tradeoff, not a free win.

Webhooks, Caching, and Stale Content

Once content and commerce live apart, freshness becomes your job. Strapi can send webhooks on events like entry.create, entry.update, entry.publish, and entry.unpublish. For most events, the payload contains the full entry with its relations and components.

A common pattern is to call your frontend when an editor publishes. The frontend then revalidates the affected page. In Next.js, that's on-demand revalidation.

Two details matter to me. First, secure the endpoint. Strapi lets you configure webhook headers, so verify them. Second, don't treat a webhook as a guarantee. I'd add a scheduled reconcile job, so one missed event doesn't leave a page stale for days.

Preview needs thought too. Editors want to see drafts. The preview route has to read draft content from Strapi and still fetch live commerce data. Test that path early. In my experience it breaks more easily than the published path.

Where Strapi Earns Its Place

I like Strapi when content needs real structure. Components and Dynamic Zones let editors assemble pages from approved blocks. REST and GraphQL let each channel request what it needs. Backend customization is real, and you can self-host it.

Next to Medusa, the split is clean. Medusa handles products, variants, pricing, carts, and orders through its commerce modules. Strapi handles guides, campaigns, FAQs, and reusable blocks. Different problems, different systems.

But using both increases what you own. That's two deployments, two upgrade paths, two permission models, and one more integration to monitor. Strapi 5 also changed core APIs, so I check version support before depending on any community plugin. If you want a closer look at the implementation side, this page on Strapi development services covers content models, integrations, and upgrades.

When I Wouldn't Add Strapi

The commerce platform already covers your content needs
Nobody owns hosting, upgrades, and security
The team wants fully managed infrastructure
Another CMS fits your editor workflow better
The design needs the CMS to duplicate operational data

The last one is a design problem, not a tooling problem. If the plan requires copying prices or stock into the CMS, I'd fix the plan before choosing software.

What I Ask Before Installing Anything

Who owns each field? What happens when that owner is unavailable? How does a content change reach the storefront? Who patches the CMS? Who owns the integration between systems?

If I can't answer those in plain language, the CMS isn't the next step. A missing answer usually means two systems will fight over the same data later.

The Principle I Keep

I still like Strapi. I just don't start there anymore.

I start with one page that says who owns what. Once that page is honest, the CMS choice gets smaller and calmer. Sometimes the answer is Strapi. Sometimes it's something simpler. Either way, the stack has fewer arguments waiting to happen.