Composable commerce: a reality check for companies that are not Zalando
The MACH pitch sounds like freedom. What a 40-person wholesaler actually buys is five vendors, five contracts and an integration layer nobody put in the budget. When composable wins — and when a monolith with a good API is the adult choice.
Photo: free stock photography (Unsplash licence) — see imprint
Composable is not an architecture, it is a procurement decision
The pitch goes like this: stop buying one big system that does everything mediocrely. Buy the best search, the best CMS, the best checkout, the best PIM, and wire them together with APIs. Swap any piece out when something better appears. It is a genuinely good idea, and every word of it is true — for a certain kind of company, which is almost never the company sitting across the table from us.
What nobody says out loud in the workshop is that composable does not remove complexity. It moves it. The complexity that used to live inside one vendor's codebase — where it was their problem, their tests, their upgrade path — now lives in the space between five vendors, where it is entirely yours. You did not simplify anything. You took delivery of an integration project and called it an architecture.
Five vendors means five contracts, five roadmaps and five on-call rotations
Draw the org chart of a composable stack honestly. Somebody renews five contracts with five renewal dates and five price-increase letters. Somebody reads five changelogs, because each vendor ships breaking changes on their own schedule and none of them coordinate with the others. Somebody owns the phone at 3am when checkout is down, and the first forty minutes of that call are spent proving which of the five it is before anyone can fix anything.
In a 40-person wholesaler that somebody is one person. Often it is the same person who also does the ERP, the EDI feeds and the warehouse printers. The MACH case studies you were shown were built by platform teams of fifteen engineers who do nothing else. That is not a detail you can wave away — it is the entire load-bearing assumption of the model, and if you do not have it, the model does not hold.
The integration layer is the project, and it is never in the budget
Between the pieces there has to be something. Something that knows a product in the PIM is the same product in the search index and the same product in the shop. Something that retries when the tax service times out mid-checkout. Something that decides what a customer sees when the CMS says the campaign is live but the stock service says zero. That something is bespoke software you now own forever, and it appears in exactly none of the vendor pricing pages.
Price it before you sign anything. Not the licences — the glue. Every event bus, every idempotency key, every dead-letter queue, every reconciliation job that runs at night because two systems drifted apart during the day. Then price the second year, when the shiny new search vendor ships v3 and your mapping layer needs rewriting by people who have since left. This is not a reason never to build it. It is a reason to know what it costs before you tell the board composable is cheaper.
When composable genuinely wins
There are real cases, and we take them seriously. If one specific capability is your actual competitive edge — a pricing engine nobody else has, a configurator that is the reason customers buy from you, a search that understands your industry's part numbers — then that piece must not be constrained by a platform's opinion of how it should work. Pull that one piece out. Leave the rest alone.
- You have a platform team that exists on Monday and still exists next year.
- One capability is genuinely your moat and the platform genuinely constrains it.
- You run several brands or countries on shared services, not one shop.
- Your traffic profile makes independent scaling of one component a real cost line.
- You can name the component you would swap out — and when — not just 'flexibility'.
A good monolith with a decent API is not the coward's option
The word monolith is doing a lot of unfair work in these conversations. A modern platform with a proper API is not the PHP spaghetti of 2012. It gives you one deployment, one upgrade path, one support contract, one place where product, price, stock, order and customer already agree with each other — and an API in front of it if you want a custom frontend later. You are not locked in a cage. You are standing on a floor.
The honest sequencing for most mid-market B2B is boring and it works: run the platform, keep the data model clean, expose the API, and decouple exactly one thing the day it actually hurts. That day may never come, and that is a fine outcome. Composable done gradually, from evidence, is architecture. Composable done up front, from a slide deck, is a bet you fund for three years before you find out.
| Cost line | Monolith with API | Composable stack |
|---|---|---|
| Vendor management | One contract, one renewal, one escalation path | Five of each, none of them aligned |
| Upgrades | One planned project per major version | Continuous, unplanned, on other people's schedules |
| Integration code | Mostly inside the platform, mostly tested by the vendor | Yours forever, tested by you, staffed by you |
| Incident triage | One log, one stack trace | Distributed tracing is now mandatory, not optional |
| Swapping a component | Painful — this is the real trade-off | Genuinely easier, if the glue was built well |
- Composable does not delete complexity — it relocates it into a layer you now own.
- If you cannot name the component you would swap and when, you are buying a slogan.
- The integration layer costs more than the licences and appears in no vendor quote.
- Decouple one piece the day it hurts — not three years before, from a slide.
Frequently asked questions
In licences, sometimes not. In total cost, almost always yes for mid-market companies — because the integration layer, the extra monitoring, the multi-vendor incident handling and the permanent engineering capacity to maintain the glue are real budget lines that no vendor quote contains. Composable pays off when the flexibility it buys is worth more than that overhead. For most 40-person wholesalers, it is not.
No, and conflating them causes bad decisions. Headless means the frontend talks to the backend over an API instead of rendering templates in the same process — that is one decision, about one seam. Composable means the backend itself is assembled from separately bought services. You can run a headless frontend on a single platform and get most of the frontend freedom with none of the multi-vendor overhead.
Big enough that no single person leaving stops the stack — which in practice means several engineers who own the integration layer as their actual job, not as a side task next to the ERP. If your answer is 'our one developer, plus the agency when it breaks', composable will work fine for about a year and then become the thing nobody dares to touch.
Partly, and that is the honest trade-off — replacing a platform is a project, not a config change. But lock-in is not binary. Keep your product data clean and exportable, keep business logic out of theme templates, use the API for anything custom, and you keep the exit cheap enough to be real. Most companies overpay to avoid a lock-in they were never going to escape anyway.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer