Composable commerce is what you get when the “buy best-of-breed pieces and connect them” idea, which we’ve covered for content and DXPs, gets applied to selling things online. Instead of one commerce platform that does everything, you assemble your store from specialised services: one for the cart, one for search, one for payments, one for content, each chosen because it’s good at its job and connected to the rest through APIs.
The plain version: you build your commerce stack like Lego rather than buying it pre-assembled. Each brick does one thing well, and you can swap a brick without rebuilding the whole model.
That’s genuinely powerful, and it’s genuinely more work, and whether the trade is worth it comes down to one question most people don’t ask until it’s too late. I’ll get to that question, but let’s build up to it honestly rather than selling the idea first.
What’s in this guide
- What it actually means
- The problem it solves
- The one question to ask first
- What it costs you
- A readiness worksheet
- Composable, headless, MACH: the commerce version
- The stuff worth remembering
What it actually means
Traditional commerce platforms are suites. One vendor gives you the catalogue, cart, checkout, promotions, search, content, and customer accounts, all built to work together out of the box. You get a lot for one contract, and you take what you’re given.
Composable commerce breaks that suite into independent pieces you choose and connect. Your product catalogue might come from one specialist, your search from another, your checkout from a third, your content from a headless CMS, your payments from a dedicated provider. Each is accessed through an API, and something has to orchestrate them into a coherent store.
The appeal is obvious once you’ve been frustrated by a suite. If the suite’s search is weak, you’re stuck with weak search. In a composable setup you swap in a best-of-breed search service and leave everything else alone. Every part can be the best available, and any part can be replaced when something better comes along or your needs change.
The catch, equally obvious once you’ve run one, is that “something has to orchestrate them” is doing a lot of work in that sentence. The pieces don’t connect themselves.
The problem it solves
Composable commerce is a reaction to a specific, real frustration, and naming it makes the whole thing clearer.
The frustration is being trapped in a monolithic platform that’s mediocre at the things you care about most. Your business depends on search, say, and the platform’s search is average, and you can’t do anything about it because it’s welded to everything else. You want to add a new sales channel and the platform wasn’t built for it. You want to run a promotion the platform’s rules can’t express. Every improvement means fighting the system or waiting for the one vendor to get around to it.
Composable removes that trap. Because the pieces are independent, the part that matters most to your business can be the best in the market. A fashion retailer who lives or dies on visual merchandising can pick the strongest tool for that and not compromise. A business expanding into new regions can add what each market needs without re-platforming. The flexibility maps directly onto competitive advantage when your differentiator depends on one part of the stack being excellent.
For a business at real scale, whose success genuinely hinges on specific capabilities, that’s worth a great deal. Hold onto that qualifier, though, because it’s where the honest version of this lives.
What a composable stack looks like in practice
Abstract descriptions of “best-of-breed pieces” don’t land until you see one assembled, so here’s a plausible mid-sized retailer’s stack, flattened but realistic.
The commerce engine handles the unglamorous core: catalogue, pricing, cart, orders. It’s the system of record for what’s for sale and what’s been bought. Around it, everything else is a specialist.
Search and product discovery is its own service, because for this retailer search is where sales are won or lost, and a dedicated search product is far better at understanding intent than a suite’s built-in box. This is the piece they’d never compromise on, and the reason they went composable at all.
Content comes from a headless CMS, so marketing can build campaign pages and rich product storytelling without waiting on developers or fighting a commerce platform’s clumsy content tools. The storefront pulls product data from the engine and editorial content from the CMS and stitches them together.
Payments run through a dedicated provider, chosen for the regions and methods this business needs, and swappable if they expand somewhere the current provider doesn’t serve well. Checkout is where you least want to be trapped, so keeping it independent has real value.
The storefront itself, the thing shoppers actually see, is a custom front end that talks to all of the above through APIs. This is the headless part: the presentation layer is fully separate from the engine, so a redesign doesn’t touch the commerce logic underneath.
Now look at what holds it together, because that’s the whole point. Between every one of those boxes is an integration, a piece of software someone wrote and someone maintains. Search has to stay in sync with the catalogue. The storefront has to handle the payment provider’s responses. When any vendor changes an API, a connection needs attention. The diagram people draw has neat lines between the boxes. Those lines are the actual work, and they’re never finished.
That’s composable commerce in one picture: excellent specialised pieces, and a permanent job keeping them connected. Whether that picture excites you or exhausts you is a fairly reliable signal about whether it’s the right choice for you.
The one question
Here’s the question to ask before you commit, and it’s not about features or vendors.
Who is going to own the integration, forever?
Composable commerce is not a product you buy, it’s a system you assemble and then maintain. The pieces connect through APIs, and those connections are software you’re responsible for. When the payment provider changes its API, someone updates the integration. When search and catalogue fall out of sync, someone debugs it. When you add a service, someone wires it in. That work never ends, because the pieces keep evolving independently underneath you.
If you have a strong engineering team who want that control and can sustain it, the answer to the question is clear and composable can be excellent. If your honest answer is “we’d figure it out” or “the agency would handle it,” slow down. An assembled stack with nobody durably responsible for the connections degrades into a set of services that don’t quite talk to each other, which is worse than the monolith you left, and more expensive.
I put this first because everything else, cost, flexibility, time to market, follows from it. The teams that succeed with composable commerce treat integration as a permanent capability they own. The teams that fail treat it as a project that ends. The architecture is the same in both cases. The outcome isn’t.
What it costs you
Beyond the integration ownership, a few costs deserve naming plainly, because the pitch tends to skip them.
You’re paying more vendors. Instead of one commerce contract you have several specialist subscriptions, plus the internal cost of connecting and maintaining them. Sometimes the total is lower than the monolith, often for a fast-moving business it’s justified, but “composable saves money” is not a safe assumption. Price it out properly.
Time to first launch is usually longer. A suite gives you a working store relatively quickly because it’s pre-integrated. A composable build starts with assembly, and assembly takes time before anything sells. You’re trading a slower start for faster changes later, which is a good trade if you’ll be changing things a lot and a poor one if you won’t.
Debugging gets harder. When a customer can’t check out and the problem could be in any of five connected services owned by four vendors, finding and fixing it is more involved than in a single system where one vendor owns the whole path. You gain resilience in that no single failure need take everything down, and you add complexity in that failures are harder to trace.
Accountability spreads. With a suite, one vendor is responsible when something breaks, and you have one number to call. With composable, responsibility is distributed across every provider in the stack, and “whose fault is this” can itself become a time sink while each vendor points at another. This is manageable with good monitoring and clear ownership of each integration, and it’s a real cost that doesn’t show up on any price list.
None of this is a reason to avoid composable commerce. It’s the actual shape of the commitment, and going in with eyes open is the difference between it working and it not.
A readiness worksheet
The decision turns on capability, scale, and whether your differentiator depends on a specific part of the stack, far more than on the architecture being fashionable.
We’ve put it into a short readiness worksheet: a scored check on integration ownership, engineering capacity, how much your competitive advantage hinges on one or two capabilities, and the scale you operate at, plus a two-column cost comparison against staying on a suite, including the integration and maintenance lines. Fill it in with your technical lead present. The integration-ownership question is the one to answer honestly first, because if that answer is shaky the rest doesn’t matter.
The commerce version
Composable, headless, and MACH all show up in commerce conversations, and here’s how they line up specifically, since we’ve covered them generally elsewhere.
Headless commerce means separating the storefront, what shoppers see, from the commerce engine underneath, connecting them by API. It lets you build any front end you like on top of your commerce logic. It’s one piece of the composable picture, and you can be headless without being fully composable.
MACH is the set of technical principles, microservices, API-first, cloud-native, headless, that a rigorous composable commerce setup tends to follow. It’s the architectural discipline behind doing composable well.
Composable commerce is the broader strategy: build your commerce capability from best-of-breed, swappable pieces rather than one suite. Headless is usually part of it, MACH describes how it’s built, and composable is the overall approach.
In practice people use these words loosely and somewhat interchangeably. The thread is the same one running through everything we’ve written on this: assemble from independent parts rather than buy a monolith, gain flexibility, take on integration. Whether that’s right for you depends on the answer to the ownership question, not on which term is in this year’s headlines.
The stuff worth remembering
- Composable commerce means building your store from best-of-breed, API-connected pieces rather than one suite. Lego, not a pre-built model.
- It solves a real trap: being stuck with a monolith that’s mediocre at the thing your business most depends on.
- The question to ask first is who owns the integration, forever. It’s a permanent capability, not a project. If the answer is shaky, stop there.
- It usually costs more vendors, a longer first launch, and harder debugging, in exchange for faster change later. Price it honestly rather than assuming it’s cheaper.
- It suits businesses at scale whose competitive advantage depends on specific capabilities being excellent, with the engineering to sustain the connections.
- Headless is one piece, MACH is the discipline, composable is the strategy. The vocabulary blurs; the underlying trade doesn’t.
- If you’re a smaller operation or your needs are well served by a good suite, the suite is very likely the better choice. Fashion is a poor reason to take on integration work.
Not sure whether composable is right for your business?
If composable commerce is on the table, look at headless commerce, how they differ, and the MACH architecture behind them.
The useful version of this conversation starts with two questions: what does your business genuinely compete on, and who would own the integration if you went composable. If you’d like a second opinion on whether the flexibility earns its cost for you, or whether a strong suite would serve you better, get in touch and we’ll work through it with you.