For a decade, the case for composable commerce had a villain. The villain was lock-in, the suite vendor who owned your storefront, your checkout, your product data, and your roadmap, and who you could not leave without a re-platforming project that took a year and frightened the board. Composable was sold as the escape. Decouple the front end from the commerce engine, assemble a stack from best-of-breed APIs, and you would never be trapped again. Swap any piece whenever a better one appeared. The pitch was freedom, and it was persuasive enough that the MACH Alliance, the vendor body behind microservices, API-first, cloud-native, and headless, turned it into something close to industry consensus.
The pitch had one flaw. It treated lock-in as a thing you could delete. Lock-in is not a thing. It is a property of any system you depend on to make money, and depend on you do. Composable commerce does not remove that dependency. It takes the dependency you could see, name, and put a renewal date on, and spreads it across a web of integrations, a custom orchestration layer, the integrator who built that layer, and the handful of developers who understand it. The lock-in did not leave. It moved somewhere harder to see and, often, harder to leave.
Origin: how lock-in became the enemy
The frustration was real. The monolithic commerce suite, Adobe Commerce in its Magento years, Salesforce Commerce Cloud, SAP Commerce Cloud, gave you everything in one box. That was the appeal and the trap. Everything in one box meant the catalog, the cart, the promotions engine, the content management, and the checkout were one vendor's code, on one vendor's release cycle, priced as one contract. Wanting a better search experience meant fighting the suite's search. Wanting a faster storefront meant fighting the suite's templating. The box did not bend, so teams customized around it, and every customization made the eventual exit more expensive.
commercetools coined the headless label, the MACH Alliance gave the architecture a banner, and the argument wrote itself. Break the box into parts. Buy search from a search specialist, content from a content specialist, payments from a payments specialist, and connect them through APIs. Each part competes on its own merits and can be replaced on its own. No single vendor holds the whole relationship hostage. By the mid-2020s the idea had clearly won the enterprise conversation. The MACH Alliance has cited survey work putting composable adoption across a large majority of the brands it studies, and Gartner has guided that most organizations buying digital experience technology would be steered toward composable rather than monolithic suites.
It was a good argument against the monolith. It was not proof that dependency had been solved. It had only moved.
Present: the four places the lock-in went
Pull a composable stack apart and the dependency is still there. It just sits in four new places, and most buyers price none of them honestly.
The first is the web of integrations itself. A monolith has one vendor relationship. A composable stack has one for the commerce engine, one for search, one for the content layer, one for the order management system, one for payments, one for the product information system, and more. Each is a contract, a renewal, a support tier, a security posture, and a roadmap you do not control. The connective tissue between them is not free either. Replacing the search vendor in a true monolith is a configuration change. Replacing it in a composable stack means re-pointing every integration that read from or wrote to it, re-testing the data contracts, and hoping the replacement's data model is close enough that the orchestration layer does not need rewriting. That is point-to-point sprawl, and practitioners describe it precisely: you can still replace a component, but the replacement triggers a chain reaction that slows the roadmap. The freedom to swap any piece is real on a slide. In a running system, every swap pulls threads attached to everything else.
The second is the custom integration and orchestration layer. The best-of-breed parts do not assemble themselves. Something has to translate between the search vendor's idea of a product and the commerce engine's idea of a product, route events between services, reconcile inventory across systems, and present one coherent thing to the storefront. That something is middleware, and almost nobody buys it off the shelf. Most enterprises build it. The result is a bespoke piece of software, an API gateway, an event bus, a backend-for-frontend, that no vendor supports, documents, or will fix at three in the morning. It is the part of the stack most central to daily operation and the part with the least outside safety net. Vercel has argued that for many builds the middleware is unnecessary overhead and a modern frontend framework can carry the integration role. They have a point, and the deeper one is this: a custom orchestration layer is itself a thing you become locked into. You wrote it. You depend on it. You cannot buy your way out of it. It behaves exactly like a monolith, except you are the only vendor, with no other customers to share the maintenance.
The third is the systems integrator or agency that built the thing. A composable build is genuinely hard. Industry cost work puts the average enterprise move to a headless or composable model around 2.6 million dollars, with roughly 62 percent of organizations needing outside help to do it. That help, the systems integrator, makes hundreds of architectural decisions during the build. Which events flow through the bus and which go point to point. How the product data model is shaped. Where business logic lives. Those decisions are rarely written down in a form a second agency could pick up cleanly. The integrator who made them holds the working mental model of your commerce platform. Leaving that integrator is its own re-platforming project, because the new one has to reverse-engineer the last one's choices before it can safely change anything. You did not escape a vendor. You acquired one whose lock-in is encoded in undocumented decisions rather than a license agreement, and a license is at least easy to read.
The fourth is your own developers. A composable stack needs a standing engineering team that understands its specific shape, the custom integration layer, the quirks of each API, the way data moves. That knowledge concentrates in a few people. When they leave, it leaves with them. Analysts of composable regret describe enterprises becoming de facto systems integrators, stitching APIs, debugging data flows, and juggling vendor relationships and licenses as a permanent internal job. New hires face a long ramp before they can touch the architecture safely, because none of it is standard. This is the quietest form of lock-in and, for many companies, the most binding. You are locked in to a team, and a small one. When knowledge of the architecture lives in a few heads, every resignation is a roadmap risk.
Present: why composable can be harder to leave than a monolith
Here is the part that inverts the original sales pitch. Leaving a monolith is awful, but it is a known kind of awful. The exit is one project against one vendor. The scope is legible. Tools exist for it. The destination is a platform, also legible. Painful, expensive, finite.
Leaving a mature composable stack is worse, because there is no single thing to leave. You are not exiting a vendor. You are unwinding a web. The custom orchestration layer assumed your current set of vendors, so changing vendors means rewriting it. The integrator's undocumented decisions have to be excavated before anything is safe to touch. Institutional knowledge sits in a few heads. There is no migration tool for a one-of-a-kind architecture, because only one company runs it. The very thing that made the stack feel free, that every piece was chosen and wired by you, is what makes it yours to untangle, alone.
VTEX made this concrete when it stepped away from the MACH Alliance in March 2025. Co-CEO Mariano Gomide de Faria told a story that lands harder than any framework diagram. A retailer wanted to test a different search vendor and asked VTEX for a 30 percent discount on the platform, reasoning that switching search would take 12 people to manage. Search was about 3 percent of the platform cost. The point is not the discount. It is that in a real composable estate, a 3 percent component had grown a 12-person operational dependency, and the supposedly swappable part was not swappable in any way the original pitch would recognize. VTEX called the wider pattern a path of hidden costs and operational complexity, and described organizations drowning in APIs while burning hours building mediation layers. A platform vendor has its own commercial reasons to say so. The pattern it described is still the one practitioners report.
None of this is new in shape. Forrester, in its 2023 commerce outlook, warned that a third of digital businesses would abandon or restructure projects midstream that proved too complex to run, and that some would regret playing software company as orchestrating their own technology ecosystem outran their capacity. "Composable regret" became the name for the second and third year of a build, when the integration overhead is no longer a launch sprint but a permanent job and the maintenance bill is fully visible. The regret is not that composable does not work. It is that the dependency was never costed.
Future and impact: what genuine flexibility actually costs
The market has noticed. The mood through 2025 and into 2026 has shifted from pure MACH as gospel to a pragmatic middle: composable where flexibility genuinely pays, consolidated where it does not. Vendors now sell pre-integrated bundles and packaged business capabilities rather than a box of loose parts, an honest admission that the integration work was always the hard and expensive part, and that handing it back to a vendor is sometimes the better trade. This is not a retreat from modular architecture. It is the end of pretending modularity is free.
If you want flexibility that is real rather than rhetorical, it costs specific things, and they are worth naming.
It costs an abstraction layer you design on purpose. Real swappability comes from deciding, before the build, that no vendor's data model becomes your data model. Your systems speak your own product and order schemas, and each vendor sits behind an adapter that translates into them. Software architects call this an anti-corruption layer. It means a vendor swap touches one adapter instead of the whole estate. It is more work upfront and the only thing that makes the swap promise true later. Skip it and the first vendor you integrate deeply becomes the model everything else is shaped around, which is lock-in by another route.
It costs portability as a standing discipline, not a one-time decision. Integrations have to stay vendor-neutral and business logic out of vendor-specific corners, and that erodes under deadline pressure unless someone defends it every sprint. The hardcoded temporary integration that becomes permanent is the classic failure here. Flexibility is a property you maintain, like test coverage, or it quietly disappears.
It costs documentation and knowledge that outlives individuals. The integrator's architectural decisions, the event flows, the data contracts between services, the reasons behind them, all of it has to live in a form a new team or agency can absorb. This is unglamorous and routinely cut. It is also the difference between a stack you can hand over and one that holds your roadmap hostage to whoever happens to still understand it.
And it costs an honest count of vendors and integrations before you commit, priced as the ongoing operational load they are, not the feature list they look like on a slide. The right question is not whether composable beats monolithic in the abstract. It is whether your organization has the engineering depth, the integration discipline, and the appetite to run a small software company, because that is what a composable estate is. For a focused team with real engineering capacity and a genuine need to move faster than a suite allows, the trade is worth it. For a team without that capacity, composable does not remove the vendor. It hands you a harder one: yourself, your integrator, and a custom layer none of you can put a renewal date on.
That honest accounting is where an implementation partner earns its place. The useful work is not picking the trendiest architecture. It is mapping where your dependency actually sits today, deciding which parts of the stack genuinely deserve to be composable and which should stay consolidated, and building the abstraction and documentation that keep the swap promise real. Lock-in cannot be deleted. It can be put somewhere you chose on purpose, can see clearly, and can afford to maintain. That, and not freedom, is the honest goal.
Council summary
The post argues that composable commerce did not eliminate vendor lock-in but redistributed it into four places buyers rarely price: the web of integrations, the custom orchestration layer, the systems integrator, and the company's own developers. Every named figure was checked against its source. VTEX did suspend support for the MACH Alliance in March 2025, and the retailer anecdote (search at roughly 3 percent of platform cost yet carrying a 12-person operational dependency) is reported accurately. The Forrester 2023 prediction about a third of digital businesses abandoning midstream projects checks out, as do the cost figures near 2.6 million dollars and 62 percent needing outside help. One sentence that wrongly tied "composable regret" to crumbling user interfaces was corrected to match the sources. The reader takeaway: lock-in cannot be deleted, so the real decision is where to place it, where you can see it and afford to maintain it.
Comments