The composable commerce pitch landed cleanly in 2022 and 2023. Decouple the storefront from the commerce engine, the engine from the search, the search from the PIM. Pick the best vendor in each box. Replace any of them without replacing all of them. The acronym was MACH — microservices, API-first, cloud-native, headless — and the consultancy decks were everywhere.

Three years in, the bill has arrived. We've been tracking re-platforming announcements and talking to e-commerce leaders at retailers that went all-in on the composable rebuild, and a clear pattern has emerged in the $200M-$2B GMV tier: a meaningful share of those retailers are now planning, scoping, or actively executing moves back toward monolithic or near-monolithic platforms.

This isn't a vindication of legacy commerce platforms — those have their own well-documented problems. It's a much more specific story about what mid-market retailers underestimated when they signed the MACH contracts.

The integration tax that didn't show up in the RFP

Every operator we spoke to who's reverting flagged the same root cause: the per-vendor cost of the composable stack was visible in the original business case. The cost of holding it together was not.

The composable stack a typical mid-market retailer built in 2023 has somewhere between 8 and 15 vendors in the critical path: commerce engine, frontend framework, CMS, PIM, search, personalization, OMS, payments, tax, fraud, loyalty, reviews, subscriptions, plus the data layer connecting them. Each vendor ships independently. Each vendor's SDK has a version cadence. Each integration point is a contract that breaks when either side changes.

One VP of engineering at a specialty retailer that went composable in 2023 told us: "We replaced one vendor we hated with twelve vendors we have to negotiate with every quarter. The total contract value is similar. The total coordination cost is not even close."

The retailers reverting consistently report that 20-35% of their engineering team's capacity is now consumed by integration maintenance — keeping connectors current, debugging cross-vendor incidents, managing the data contracts between systems. That capacity was supposed to be redirected to revenue-driving feature work. It mostly wasn't.

What's actually breaking

The specific failure modes that show up most in conversations with reverting retailers:

• Cross-system incidents take longer to resolve. When checkout breaks, it could be the commerce engine, the OMS, payments, tax, or any of the connectors between them. Mean time to resolution at composable retailers is noticeably longer than at their monolithic peers, because the diagnostic surface is bigger.
• Vendor roadmaps drift apart. A search vendor optimizing for AI-native ranking and a commerce engine optimizing for B2B workflows are not solving the same problem. Two years in, retailers report their vendor roadmaps no longer feel like a stack — they feel like a portfolio of unrelated bets.
• The data layer is harder than anyone budgeted for. A composable stack only works if there's a clean, real-time view of product, inventory, customer, and order across all the systems. Most mid-market retailers underinvested here, and are now running expensive data-layer remediation projects to make the rest of the stack work as advertised.
• Hiring is worse, not better. The promise was that decoupled systems would let teams hire specialists per domain. The reality is most mid-market retailers can't hire 12 specialists, and the generalists they do hire spend their time on the integration tax described above.

The numbers operators are trying to recover

The rip-and-replace itself wasn't cheap. Retailers in this tier report total program costs for the composable migration in the $8M-$25M range depending on scope, plus ongoing run-rate increases in the $2M-$6M annual range versus the legacy platform — driven by the long tail of vendor contracts, integration headcount, and the data and DevOps tooling required to operate a multi-vendor stack.

The re-platform back toward a more consolidated architecture isn't free either. The retailers we spoke to are budgeting 18-30 months and 30-60% of the original migration cost to consolidate back, depending on how much of the composable investment they're willing to throw away versus repurpose.

The math, according to one head of e-commerce we interviewed: "We spent $14M to leave the monolith. We'll spend another $6M to come back to something that looks a lot like it. The question we ask ourselves every Monday is whether the four years between those two projects produced four years of value. The honest answer is: not really."

Who's still happy with composable

To be clear, composable is not failing universally. The retailers we talked to who are still bullish on their MACH stacks share a recognizable profile: GMV above roughly $2B, engineering organizations large enough to absorb the integration tax as a fixed cost rather than a marginal one, and use cases (B2B, marketplace, multi-brand) where the flexibility genuinely earns its keep.

Below that threshold, the calculus is different. The mid-market retailer with a 30-person engineering team and a single DTC storefront does not get four years of differentiation from picking their own search vendor. They get four years of integration meetings.

The lesson, such as it is

The composable backlash is not really about composable. It's about what happens when a mid-market business buys an enterprise architecture and discovers, slowly, that the operating model required to run it doesn't fit the org. The retailers reverting aren't admitting they were wrong about decoupling in the abstract. They're admitting that the abstract isn't where retail gets done.

For the retailers planning their next platform decision, the question worth asking isn't "monolith or composable?" It's "what's the smallest number of vendors we can build this on, given the engineering org we actually have?" That question would have saved several of the operators we talked to a great deal of money.