Posted in Digital Commerce
June 8, 2026
definition
What is decoupled commerce?
Decoupled commerce keeps a single commerce platform on the backend and runs the frontend as its own application on a separate runtime, often served from a CDN. It is the middle ground between a templated monolith and a fully composable stack. For many mid-market manufacturers, decoupled is the rational stopping point: enough flexibility to ship a custom experience, without taking on the operational tax of running every service separately.
Key takeaway
Decoupled separates the frontend runtime from the commerce backend; headless separates only the UI layer; composable separates the whole stack. Decoupled is where most B2B builds usefully land.
Decoupled defined: separated runtime, shared platform
Decoupled commerce means the storefront runs on its own runtime: its own application server (or serverless platform), its own deployment pipeline, and often its own hosting and CDN. The commerce backend stays on the platform. The two halves talk through APIs, the same way they would in a headless build, but the frontend is a fully independent application rather than a templating layer sitting inside the platform.
In practice, decoupled is what most modern "headless" builds actually are. A Next.js storefront deployed on Vercel that calls a BigCommerce backend is decoupled. A Nuxt storefront on Cloudflare Pages that calls a Shopware backend is decoupled. A Hydrogen storefront on Oxygen calling Shopify is decoupled. The frontend is its own thing. The commerce platform is intact behind it.
The platform you started on does not have to change to do this. BigCommerce, Shopify, Shopware, Magento (Adobe Commerce), commercetools, and several others all expose APIs sufficient for a decoupled build. The decision is whether the team wants to run a separate frontend application, with everything that entails, or stay on the platform's templating engine.
Decoupled vs headless: what is actually separated
The terms overlap, which is half the problem. Headless emphasizes the API boundary: the storefront talks to the commerce backend through APIs instead of being baked in. Decoupled emphasizes the runtime boundary: the frontend deploys, scales, and is hosted independently. In current usage, "headless" usually implies "decoupled" too, because a frontend that uses APIs is almost always its own application.
The cleanest mental model: headless is the architectural pattern (API-driven UI), decoupled is the operational shape (independent runtime). Most builds are both. The distinction matters when someone says "we are going headless but staying on the platform's hosting" or "we are decoupling the frontend but using the platform's templating language for some pages". Those edge cases are real and worth naming precisely so the team agrees what is being built.
For the cluster article comparing the three terms directly, see decoupled vs headless vs composable commerce.
Decoupled vs composable: scope and ownership
Decoupled changes the frontend. Composable changes the whole stack. A decoupled build keeps one commerce platform as the backbone, with the storefront running independently. A composable build replaces the platform's monolithic backbone with a set of independent services for cart, search, content, identity, payments, and so on. Composable is, in this sense, decoupled on every axis.
For most mid-market B2B manufacturers, decoupled is enough. The platform's commerce engine carries cart, checkout, and order primitives; one or two best-of-breed services (typically search or CMS) get bolted on through APIs; the frontend takes the freedom to render however the team needs. This pattern is often called augmented composable, and it sits at the centre of the cost-versus-capability curve for a lot of mid-market projects.
Composable becomes worth the additional cost when the business genuinely needs services to be swappable or when no single platform's commerce engine can carry the load. The when middleware is enough cluster article walks through the decision frame.
Decoupled BigCommerce and decoupled Shopify in the wild
Decoupled BigCommerce is one of the more mature patterns. BigCommerce's Storefront API is designed for it, and the company actively supports B2B builds running a custom frontend against the platform's commerce engine. Acro Commerce's decoupled BigCommerce service page describes the build pattern we use, with the BigCommerce backend handling catalogue, cart, and checkout, and the Next.js frontend carrying the customer experience.
Decoupled Shopify, with or without Hydrogen, is similar. The Shopify backend handles commerce; the frontend is an independent application that calls Shopify's APIs. Hydrogen smooths the path for teams staying inside Shopify's ecosystem and Oxygen handles hosting; teams that want a different stack can use the Storefront API directly. The decoupled Shopify service page documents our build pattern.
Decoupled Shopware is the third common shape we work with, especially for European B2B manufacturers. The Sales Channel API exposes commerce capabilities to a separate frontend, often paired with Storyblok for content. The pattern shows up in the Shopware decoupled case spotlight.
When decoupled is the rational stopping point
Decoupled is enough when the platform's commerce engine fits the business reasonably well, the team needs frontend independence (custom UX, faster release cadence, better performance, or multi-channel support), and the operational appetite for running many vendors is limited. The team gets the experience flexibility without taking on the cost of swapping the backend.
The signals that decoupled has run out of room and composable is the next step are specific: the platform's pricing engine cannot express the business's pricing rules even with custom development; the platform's order model cannot represent the manufacturer's split-shipment or backorder logic; or the catalogue and search experience needs to use a vendor that is not the platform's native search. When two or more of those show up, composable becomes a serious conversation. When none do, decoupled is the right answer.
For a deeper look at the decision frame, see the composable commerce definition article and the pillar hub on decoupled and composable commerce. For the cost ranges that decide whether the next step pays off, see the true cost of composable article.
Related Articles
Decoupled and composable commerce for complex B2B
- Definition: What is composable commerce?
- Definition: What is headless commerce?
- Definition: What is decoupled commerce?
- How a manufacturer modernized with Acumatica and a composable storefront
- A Shopware manufacturer goes decoupled without going fully composable
- The state of composable commerce for complex B2B in 2026
Frequently Asked Questions
What is decoupled commerce in one sentence?
Decoupled commerce is a build pattern where the storefront frontend runs as its own application on a separate runtime, while the commerce backend stays on a single commerce platform that the frontend calls through APIs.
What is the difference between decoupled and headless commerce?
Headless emphasizes the API boundary: the storefront talks to the commerce backend through APIs. Decoupled emphasizes the runtime boundary: the frontend runs as its own application, separately deployed and hosted. In current usage most builds are both, but the terms differ if someone is using APIs without separating the runtime, or separating the runtime without using APIs cleanly.
How is decoupled commerce different from composable commerce?
Decoupled changes the frontend; composable changes the whole stack. A decoupled build keeps one commerce platform as the backbone with the storefront running independently. A composable build replaces the platform with independent services for cart, search, content, identity, payments, and so on. Composable is the more expensive shape; decoupled is the rational stopping point for many B2B manufacturers.
Can BigCommerce be decoupled?
Yes. BigCommerce supports decoupled builds as a first-class pattern, with a Storefront API designed for custom frontends and explicit B2B support. The commerce engine handles catalogue, cart, and checkout while the frontend (typically Next.js or another modern framework) carries the customer experience.
Is Shopify Hydrogen the same as decoupled Shopify?
Hydrogen is one way to build a decoupled Shopify storefront, using Shopify's React framework and Oxygen hosting. Decoupled Shopify is the broader idea: any custom frontend on its own runtime that calls Shopify's APIs. A team can build decoupled Shopify without Hydrogen by choosing its own stack and hosting.
When does a B2B manufacturer actually need decoupled commerce?
When the platform's templating engine cannot deliver the experience the business needs: a multi-region or multi-brand site sharing one backend, a portal with very different UX from the public catalogue, strict performance or accessibility targets, or a content-heavy experience that has to coexist with commerce. If the platform's templates can carry the experience, decoupled adds operating cost without a clear gain.
Do I need a separate CMS for a decoupled build?
Often, yes. The platform's native templating is no longer doing the rendering, so content that used to live there has to move somewhere. Many decoupled builds add a dedicated CMS like Storyblok or Contentful to give marketers a home for content that the frontend renders alongside commerce data. Some teams use the commerce platform's content modules instead.
Next Step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.