Headless & Composable Commerce

Composable commerce is the most oversold architecture in retail technology and, for the right business, one of the most transformative. The gap between those two statements is entirely about whether you needed it. Here is how we decide, and how we build it when the answer is yes.

We argue you out of it first

The honest starting position is that most businesses asking for composable commerce would be better served by a well-built monolith or a simple headless setup. A composable stack multiplies the number of systems you run, monitor, secure and keep in sync, and it demands a platform engineering capability that many teams do not have and should not have to build. So the first thing we do is try to talk you out of it — and if the reasons survive that, you can trust the build, because it was justified rather than sold.

Headless first, composable only if warranted

Going headless — a custom Next.js storefront on top of a commerce engine — delivers most of the front-end benefit people actually want: a fast, bespoke experience, Core Web Vitals you control, and one design system across touchpoints. You can do this on top of Shopify or BigCommerce and keep their managed reliability. Full composability — swapping the single engine for assembled best-of-breed services — is a further step you take only when a single engine genuinely cannot serve your model, or when being able to replace any component without a replatform is worth real money to you.

The engine choice: managed MACH or open-source you own

When composable is warranted, the central decision is the commerce engine. commercetools is the reference managed MACH platform — API-first, powerful, with a licence to match — and it fits large enterprises that want the capability without running the infrastructure. Medusa is an open-source commerce engine you self-host and own outright, which fits teams that want composability without a per-order licence and have the engineering to run it. We build on both, and the right answer is a function of your scale, your team and your appetite for licence versus ownership.

Orchestration is the whole discipline

The failure mode of composable commerce is the distributed monolith: five services that must all be up for anything to work, with no clear owner of consistency and no visibility when one is slow. We avoid it deliberately. A backend-for-frontend gives the storefront one stable API. Integrations are asynchronous and idempotent so a slow provider cannot topple checkout. One component owns data consistency between engine, search index and CMS, with reconciliation rather than hope. And distributed tracing runs across the whole stack. Composability without this is all of the cost and none of the benefit, which is exactly the outcome this page exists to help you avoid.