The Composable Commerce Correction: Why Bundled Is Back

The B2B commerce platform market has swung through three distinct phases in the past 15 years. Monolithic suites gave way to fully composable architectures. Now, composable vendors are building bundled solutions again.

This represents a market correction that prioritises time-to-value (how quickly a project delivers a real business benefit) without abandoning flexibility.

Understanding this shift matters because platform selection decisions made today will shape operations for years. Buying into yesterday’s architectural dogma costs money and delays launches.

The pendulum swung three times

Ten years ago, commerce platforms were monolithic. One tightly coupled application where catalogue, cart, checkout, content, and search tend to live in a single codebase. Customisation meant fighting the platform’s assumptions about how commerce should work.

Then, headless architecture emerged. The front-end (the website or app) is separated from the commerce engine (products, pricing, checkout, orders) and connected via APIs. Decoupled front-ends opened new possibilities for front-end development. Speed and flexibility improved for teams with technical capability.

The market pushed further. Composable commerce promised best-of-breed everything. Build your stack from specialist services designed to integrate via APIs, then swap parts over time. Search from one provider. A CMS (a system for managing pages and editorial content) from another. Payments from a third. Commerce engine from a fourth.

The pivot back isn’t a retreat. Composable vendors are now bundling search, CMS, and visual page builders (drag-and-drop tools that let non-developers assemble pages from pre-built components) into their offerings. Elastic Path, a company built on composable principles, is doing exactly this.

10 years ago, everything was monolithic and tightly coupled. Then pivoted far to fully composable, with very much a religious fervour about how to approach composable. It’s pivoting back.

Bryan House

The supermarket problem made it hard to sell

Many of us do our weekly shop in one supermarket. Composable architecture is closer to visiting a different shop for every ingredient. The result might be better produce, but the logistics are harder work.

Composable commerce asks businesses to change how they think about buying technology. It promises a better meal. It also gives you ten shops, ten receipts, and ten people to call when something is missing.

For mid-market manufacturers and distributors with small technical teams, this often creates paralysis. The theoretical flexibility does not outweigh the day-to-day reality of managing multiple vendors, separate integration agreements, and fragmented support.

Decision fatigue becomes part of the project. Teams spend months comparing search providers before they have even settled on the core commerce platform.

Bundled composable still needs engineering discipline

Bundling reduces vendor sprawl. It does not remove integration work.

B2B commerce is heterogeneous by definition. You still need to connect ERP, PIM, CRM, pricing logic, tax, payments, and identity. Those connections are where trust breaks down when teams rush.

Bundled platforms help because the internal pieces are already wired. Search and CMS are built to the same assumptions as the commerce engine, with fewer unknowns at the edges.

You still need to be deliberate about boundaries. 

• Keep business logic out of templates. 
• Keep custom pricing rules in one place. 
• Stop teams from building undocumented one-off integrations that nobody can safely change later.

The citizen builder promise didn’t materialise

A common pitch for composable platforms was that business users would assemble applications using low-code or no-code tools. Citizen builders (non-developers using approved tools to configure apps and workflows) would reduce dependency on technical teams.

This largely hasn’t happened.

As Bryan put it, “This idea that citizen builders are going to come in and develop a commerce app, I just think it’s not real. We certainly haven’t seen a lot of success with that.“

The comparison to Shopify is instructive. Shopify is often positioned as a business-user-friendly platform, similar to how WordPress dominates the CMS space. Yet agencies remain involved in the work. Technical support is still required.

AI is making great strides in changing this, and every day we get a little closer to the original vision. Shopify have added an AI builder, MCP and a hybrid tool to build your own site.

Commerce is complex. Order management, pricing rules, inventory synchronisation, tax calculation,and payment processing. These systems require expertise to configure and maintain. The citizen builder narrative oversimplified what it takes to run B2B commerce.

And I will continue to come back time and time again

A good story in any language is a good story, and technology is the language. Not the story.

It doesn’t matter how good a drag and drop editor is, or AI, it’s the use,r whether that be dragging and dropping or prompting, that makes the difference.

“Good enough at the right price” is a legitimate strategy

There is however, a pragmatic reality that got lost in the composable excitement.

Within a commerce stack, there are capabilities where being good enough at the right price solves the problem. Time to value, cost of implementation, and contract consolidation become important decision factors.

A best-of-breed search solution might offer 15% better relevance than a bundled option. Whether that 15% justifies separate contracts, additional integration work, and another vendor relationship depends entirely on the business.

For a manufacturer with 5,000 SKUs (the internal identifier for a specific product or variant) selling to trade customers who already know what they want, the bundled search might be entirely sufficient. For a distributor with 500,000 SKUs where product discovery drives conversion, the investment in best-of-breed search makes sense.

The needs-first approach I’ve written about previously applies directly here. Using frameworks like SPIN APE, teams can define specific requirements before evaluating whether bundled or best-of-breed serves their operation better.

“Swap later” is real work, not a promise

The bundled composable pitch is simple. Start with the bundled stack, then replace parts when you outgrow them.

That only holds if your implementation treats those parts as replaceable from day one.

In practice, swapping a component usually means rebuilding at least one of these:

• The data model feeding it (products, attributes, pricing, availability, content relationships)
• The integration pattern (API calls, events, batch jobs, retries, error handling)
• The operating model (who owns it, who supports it, what breaks the build)

Search is a good example. Replacing search is not just changing a vendor. You are changing indexing pipelines, relevance tuning, synonyms, permissions, and analytics.

A CMS replacement often means content migrations, rewritten page templates, component libraries, and new editorial workflows. The marketing team feels every change.

The way to keep swapping viable is to design your integration layer. Put adapters between your platform and external services. Version your interfaces. Write down the contract, then build to the contract.

Bundled composable preserves flexibility without the startup cost

The new breed of bundled composable platforms offers an interesting proposition.

Start with integrated components that work together out of the box. Get to market faster with fewer contracts and reduced integration complexity. Then, because the architecture remains composable, swap out individual components when business needs justify the investment.

Bryan described this approach: “You don’t lose flexibility of composability, but you don’t have to start there by buying different technologies. Because it’s composable, you can swap out those at any time and drop in the right one for your business.”

This addresses the primary objection to monolithic platforms: being locked into inadequate capabilities. The escape hatch exists. The question becomes whether the business needs to use it, and when.

Phase one might use bundled search and CMS. Phase two, after proving the business case and learning customer behaviour, might introduce specialist search. Phase three might swap the CMS for a headless content platform that supports multiple channels.

The architecture supports this evolution. The commercial model doesn’t force it from day one.

A phased roadmap example for a mid-market distributor

The pattern that works is not “pick the perfect stack”. It is “ship the next slice of value, then improve”.

Phase 1: Make ordering boring and reliable

Get the account login working. Get contract pricing right. Get stock visibility accurate enough that sales teams stop apologising.

If that means using bundled search and a basic CMS at first, that is fine. You are removing friction from the order path.

Phase 2: Improve discovery where it matters

Work out where buyers get stuck. Site search is often the bottleneck in large catalogues, especially when product names and industry terms do not match.

Improve filters, synonyms, and structured attributes. Improve product data quality before blaming the platform.

This is the point where specialist search can pay for itself. You have usage data, and you know what buyers type.

Phase 3: Automate the parts sales teams repeat all day

Quoting, approvals, and negotiated pricing are workflow problems. They are rarely solved by a prettier storefront.

This is where composable architecture earns its keep. You can bolt on workflow automation and seller-assisted tools without rebuilding your whole stack.

How to evaluate whether bundled suits your business

The choice between bundled composable and full best-of-breed depends on specific factors.

Consider bundled composable when:

• Technical team capacity is limited
• Time to launch is a priority over maximum capability
• The use case is well-defined and mainstream
• Reducing vendor management overhead matters
• Budget requires predictable costs rather than ongoing integration investment

Consider best-of-breed composable when:

• Specific capabilities provide competitive differentiation
• The technical team can manage multiple integrations effectively
• The use case requires specialist functionality unavailable in bundled options
• Scale demands performance characteristics only available from specialist providers
• Long-term flexibility outweighs short-term complexity

Neither approach is inherently superior. The right choice depends on where the business sits today and where it intends to go.

A small amount of evidence, with clear caveats

Vendors publish research that supports their own positioning. It is still useful as a directional signal when you treat it as vendor data.

The MACH Alliance publishes annual research on adoption and outcomes. Their 2025 release states that 87% of organisations widely using MACH reported that their approach met or exceeded ROI expectations.

Commercetools published a 2025 release stating that 88% of enterprises plan to modernise commerce platforms within 12 months, framed around AI readiness.

The market correction serves buyers

This shift toward bundled composable represents the market responding to buyer needs rather than architectural ideology.

Vendors discovered that selling flexibility alone wasn’t enough. Customers needed faster time-to-value and simpler commercial arrangements. The composable architecture remained valuable, but the go-to-market packaging needed refinement.

For B2B businesses evaluating platforms now, this correction creates better options. Bundled composable offers a middle path between the rigidity of traditional monolithic platforms and the complexity of assembling a stack from scratch.

The pendulum will probably swing again. I recall sitting down with the leadership at BigCommerce nearly 2 years ago, talking about SaaS being great and all that, but people will be people, and some will want on-prem because they believe they have a competitive edge. Architectural preferences cycle. What matters is selecting a platform that serves current business needs whilst preserving reasonable optionality for the future.

1. Start with documented requirements.
2. Understand what “good” looks like for the next 18 months.
3. Then evaluate whether bundled or best-of-breed better serves those specific needs.

The platform should follow the plan. The plan shouldn’t follow the platform.

Quick definitions for skimmers

SPIN APE®: A Two-Part Framework for B2B Platform Selection. Situation, Purpose/Problem, Impact, Implication, Needs, Align, Propose, Evaluate.

Monolithic platform: One tightly coupled application where most commerce functions live together, so changing one part tends to impact others.

Headless: A separated front-end and commerce engine connected via APIs, so channels can change without rebuilding the core.

Composable commerce: A stack built from independent services (commerce engine, search, CMS, payments) designed to integrate via APIs and be swapped over time.

Best-of-breed: Picking the strongest product in each category rather than taking one vendor’s full suite.

MACH Alliance: An industry group promoting Microservices, API-first, Cloud-native SaaS, and Headless approaches. It influences language and vendor positioning, rather than acting as a regulator.

Citizen builder: A non-developer using approved no-code or low-code tools to configure apps and workflows.

Time-to-value: The time between starting a platform project and seeing a meaningful business benefit.

Integration contracts: The documented rules for how systems exchange data and what changes are safe, so upgrades do not break production unexpectedly.

SKU: The internal identifier for a specific product or variant, used for stock, ordering, and reporting.