Composable is not a strategy

A conviction that became a reflex

Ten years ago, the question was which platform to choose. Today, part of the market has answered for you: the future is composable, decoupled, API-driven, and the monolith is debt waiting to happen. Vendors, integrators and analysts repeat the same message, with real arguments: freedom of choice, scalability, faster front ends.

The problem is not that these arguments are wrong. It is that they are presented as universal. An architecture is not a belief; it is a trade-off between the flexibility you gain and the complexity you pay for. That trade-off depends on the company, not on the decade.

What composable promises, and what it costs

The promise is compelling: each capability (catalogue, cart, search, content, payments) becomes an independent component, replaceable without touching the rest. The front end can change without touching the commerce engine. A new channel plugs into the same services.

The cost is rarely spelled out. It comes down to four words:

• Orchestration. Someone has to make components work together that were not designed to, and keep them consistent every time one of them updates.
• Accountability. When an order fails, you need to know which component is at fault. In a monolith, there is one answer. In a composable stack, it may involve four vendors.
• Observability. Each component has its own logs, outages and limits. Bringing them into one reliable view is a project in itself.
• Vendor management. Four contracts, four roadmaps, four pricing policies that change independently.

That cost does not show up at launch. It settles in afterwards, every month.

The three conditions for payback

Composable pays off when what it gains durably exceeds what it costs to run. In practice, that takes three conditions together.

1. Genuinely different channels. A website, a B2B sales-rep portal, a mobile app and an in-store terminal, each with its own experience. If your only channel is a website, decoupling the front end adds little.

2. A high and uneven pace of change. The benefit of composable comes from evolving one domain without touching the others. If pricing changes weekly but the catalogue is stable, decoupling makes sense. If everything moves slowly, it does not.

3. A team able to own the assembly. An architecture owner, mature operations, automated testing, API governance. Without that capability, in house or through a long-term partner, a composable stack degrades faster than a monolith.

One condition is not enough. Two out of three justify a serious study. All three justify the investment.

The Nuevamed decision matrix

The modular monolith, the forgotten option

Between the classic monolith and a fully composable stack lies a path rarely promoted, because it does not sell well: a single application, organized into clearly separated domains (catalogue, pricing, orders, customers) that communicate through clear interfaces.

It delivers most of composable's clarity without its operating cost. It deploys as one unit, is monitored from one place and belongs to one team. Above all, it prepares the future: the day a domain truly justifies being extracted, the boundary already exists.

For most of the mid-market companies we meet, this is the right answer. It just is not fashionable.

Migrate by domain, not all at once

When composable is justified, the worst approach is replacing everything at once. The safest is extracting one domain at a time, starting with the one that changes most often and costs the most to change: very often pricing or search.

The rest of the platform keeps running in the meantime. Each extraction is measured before deciding on the next. If the gain is not there, you stop, without having put the business at risk.

When we recommend Shopflow, and when we do not

Shopflow, our platform, is API-first. It would be easier for us to recommend a decoupled architecture to every client. We do not.

We recommend Shopflow when B2B logic (negotiated pricing, customer-specific catalogues, tight ERP integration) is at the heart of the business and several channels need to share that logic. We recommend something else when the business model is close to a SaaS platform's standard, or when the organization does not yet have the capacity to run an open architecture. In that case, a more integrated solution, even a less flexible one, will cost less and deliver faster.

Conclusion

Composable is a powerful tool, not a destination. Companies that adopt it out of conviction pay its cost without getting its benefit. Those that adopt it by calculation, domain by domain and when their three conditions are met, get exactly what it promises. Architectural maturity is not measured by how decoupled a system is, but by how well its complexity matches the capacity of the organization that runs it.

Nuevamed designs and evolves monolithic, modular and composable platforms, including on Adobe Commerce and through our web and software development teams. To estimate the real cost of each option, read Platform cost is decided in integration.