Composable Regrets: Lessons From the First Wave

Written by Filip Bech-Larsen

Composable architecture entered the scene with a promise of freedom, flexibility, and innovation. For many enterprises, that promise still holds true, but the journey has revealed challenges along the way. This blog looks at what we've learned from the first wave of composable adoption and how a more practical approach can unlock its full potential.

When composable architecture first burst onto the enterprise technology scene, it carried with it a powerful promise: freedom. Freedom from vendor lock-in. Freedom to select the best tool for the job (best-of-breed). Freedom to scale and innovate at the speed of change.

For many digital leaders, that promise was too compelling to ignore. They plunged headfirst into composable, eager to architect stacks that could flex and evolve alongside their business ambitions. But today, just a few years later, an uncomfortable truth is emerging: the promise hasn’t always matched reality. Many enterprises are now quietly shouldering what I call composable regrets.

The Burden of Orchestration

One of the first regrets stems from underestimating the sheer effort of orchestration. What looked on paper like a neat collection of interchangeable components often turned into an ongoing integration project. Enterprises became de facto system integrators, stitching APIs together, debugging data flows, and managing a growing set of vendor relationships.

Instead of freeing teams to focus on innovation, composable stacks often left them bogged down in plumbing. Engineering backlogs swelled. Marketing teams waited weeks for changes. What should have been agility became inertia.

The Hidden Cost of Complexity

Another regret is financial. Composable was supposed to bring cost efficiency—pay for only what you need. Yet, when you layer licensing, integration, custom development, and ongoing maintenance, many organizations have ended up paying more, not less. Worse, those costs don’t always translate into business value.

This complexity tax has become a drain not only on budgets but also on talent. Teams trained to deliver great digital experiences find themselves acting as full-time integrators (or debuggers), a role that quickly leads to burnout and disillusionment.

The Experience Gap

Perhaps the most painful regret is customer-facing. End users don’t care how many systems sit behind their digital experience, they only care that it’s fast, seamless, reliable, and engaging. Too often, composable journeys feel disjointed. Personalization doesn’t connect across channels. Content and commerce feel stitched together. What should have been a better experience becomes a fractured one.

Regrets as Teachers

The conclusion is not that composable was a mistake. Far from it. The flexibility it promises is real and necessary. But regrets are powerful teachers, and the first wave of composable adoption has exposed the gaps.

The lesson is that composability without clarity is chaos. The future must be about practical composability: solutions that provide openness and choice while reducing the burden of orchestration. Architectures that prioritize experience over integration. Platforms that empower teams to deliver, not just assemble.

We need a shift from composable at any cost to composable that delivers.

Enterprises that learn from the regrets of the first wave will be best placed to harness the true potential of composable in the next.