MACH and Composable Commerce: The Numbers Have Turned, and Both Sides Are Quoting Real Data

Two credible research firms published numbers this year that point in opposite directions, and if you're making an architecture decision you're going to be shown whichever one supports the sale.

Gartner's line is that at least 70% of organisations will be mandated to acquire composable DXP technology by 2026, up from 50% in 2023^[1]. Futurum surveyed 830 IT decision-makers and found best-of-breed procurement has fallen to 20.7%, down 3.6 points in six months, with 41% of enterprises actively planning to reduce or consolidate their application count, and 65.9% now following a "mostly platform" model, up from 60.0%^[2].

Composable adoption up. Best-of-breed buying down. Both sourced. Let's work out how both are true.

One caveat on the first number before we go further. That Gartner prediction reaches you through the MACH Alliance, the industry body whose members sell composable technology^[1]. Worth holding it a little more loosely than the Futurum figure, which comes with a named survey, a sample size and a publication date attached to it.

What MACH actually means, minus the marketing

MACH stands for Microservices, API-first, Cloud-native, Headless. It's an architectural pattern promoted by the MACH Alliance, which describes itself as the industry body for open, composable and connected enterprise technology^[3].

Composable commerce is the commerce-specific version: assemble your stack from independent services rather than buying one platform that does everything. Product management from one vendor, search from another, checkout from a third, CMS from a fourth.

The pitch is straightforward and mostly correct on its own terms. Swap any component without replatforming. Scale each piece independently. Never wait for a vendor's roadmap.

The thing the acronym hides

Every one of those four letters describes a property of your vendors. None of them describes a property of your team.

Microservices means someone operates the service boundaries. API-first means someone writes and maintains the integrations. Cloud-native means someone owns the infrastructure. Headless means someone owns the frontend, permanently.

MACH is a shopping list that quietly implies a hiring plan, and the hiring plan is never on the slide.

How both research findings are true

Here's the reconciliation, and I think it's the most useful thing in this article.

The two datasets are measuring different layers. Gartner is measuring architecture: are your systems API-addressable, independently deployable, replaceable in principle. Futurum is measuring procurement: when you buy something new, do you buy the specialist or the suite^[2].

An enterprise can absolutely run a composable architecture and buy fewer, larger vendors within it. That's not a contradiction. It's maturity. The first wave of composable meant fifteen vendors because that's what "best-of-breed" implied. The second wave keeps the architecture and consolidates the vendor list.

And Futurum names the driver explicitly: AI. Streamlining the use of AI agents ranks alongside reducing IT complexity and improving data exchange as a leading motivation for consolidation^[2].

That makes sense once you think about what an AI layer needs. It needs to see across your product data, your stock, your orders, your support tickets and your returns at once. Fifteen vendors with fifteen data models makes that expensive. This is the first genuinely new argument against extreme best-of-breed in about a decade, and it's an argument that didn't exist when the composable wave started.

Does composable actually apply to you?

Revenue is the honest cut, and I'll be blunter about it than most people are.

Under £5M. No. The integration ownership cost dominates everything and there is no version of this that pays back. Buy a platform.

£5M to £15M. Almost certainly no, with one exception: a genuinely unusual business model that no platform models properly. Rental, subscription boxes with complex logic, marketplace mechanics, heavy B2B pricing rules.

£15M to £150M. This is where the real argument lives, and where the answer is properly contested. You have the team, or you can build one. You have specific requirements. You also have the most to lose from an eighteen-month migration.

£150M+. Usually yes, and usually already partially done.

The mid-market band is the interesting one because that's where the sales effort concentrates and where the failures are most expensive.

What we found: the licence is 20-40% of the bill

Here's the cost pattern that shows up consistently across published implementation data and is almost never in a vendor's ROI model.

The platform licence typically represents only 20 to 40% of total project cost. The remaining 60 to 80% goes to implementation, ERP integration, data migration, QA and delivery work^[4].

So a $40,000 licence is a $100,000 to $200,000 project in year one, and that ratio holds roughly at every scale. Elogic's replatforming index puts a mid-market ecommerce replatform at $150K to $300K all-in over 5 to 10 months, and enterprise composable rebuilds at $500,000 to $2,000,000^[5].

Both of those sources are agencies that sell implementation work, so read them as informed rather than disinterested. The direction is corroborated by the fact that neither has an incentive to make the number smaller.

The licence numbers for comparison

commercetools, the most prominent composable commerce backend, doesn't publish pricing. Third-party procurement data puts most contracts in the $40,000 to $300,000+ per year range on licence alone, with enterprise deployments well above that^[6]. Apply the 20-40% rule and the true year-one number is uncomfortable.

Against that, Shopify Plus starts from £1,800/month^[7], which is roughly £21,600 a year with the frontend, checkout, hosting, PCI compliance and an app ecosystem included. BigCommerce Performance starts around $1,499/month on annual billing^[8]. Adobe Commerce licences are quote-only and scale with GMV.

That gap is the actual decision. Not architecture philosophy. The gap between £21,600 all-in and a $40,000 licence that's 30% of a $130,000 project.

The ongoing cost nobody models

Integration maintenance doesn't finish. Every vendor in your stack ships breaking changes on their own schedule, and you own the reconciliation.

Shopify alone ships a new API version quarterly, with a minimum of 12 months support and at least nine months of overlap between consecutive versions^[9]. That's one vendor with unusually good deprecation discipline. Multiply by eight to fifteen vendors, most with worse discipline, and you have a permanent engineering commitment that shows up as "maintenance" in a budget line and as "why can't we ship anything" in a board meeting.

Practical constraint worth writing on a wall: if you don't have at least two engineers comfortable with APIs, event-driven architecture and CI/CD, you will struggle to operate a composable stack regardless of which vendors you pick^[4].

The failure modes, named

Composable projects don't usually fail dramatically. They fail slowly, in one of four recognisable ways, and knowing the shape helps you spot it early.

The integration graveyard

You connect eight vendors. Each integration is written by whoever was available. Nobody documents the contracts. Two years later three of the original developers have left and nobody knows what breaks if the PIM changes a field name.

The tell: someone says "we can't upgrade that because we're not sure what depends on it." The fix, applied at the start rather than year three, is a written contract per integration and one person who owns the map.

The frozen middle

The architecture is genuinely composable and nobody dares change anything, because the blast radius of a change is unknown. You have all the coupling of a monolith and none of the safety of one, because at least a monolith has a test suite that covers the whole thing.

The vendor that disappears

Every service in your stack is someone else's business, and businesses get acquired, repriced or shut down. The commerce space has plenty of recent examples: Shogun retired its headless frontend in March 2023 after three years and 50+ live storefronts^[17], and Adobe stopped actively developing PWA Studio in 2024^[11].

Ask the question at procurement: what's our exit path from each vendor, and how long would replacing this one take. If the answer for any single component is over three months, that component isn't really swappable, which means you paid for optionality you don't have.

The data model that never got designed

The most expensive one. Each service has its own idea of what a product is, what a customer is, and what an order is. No canonical model was ever written down, so every integration includes a translation layer, and the translation layers disagree.

This is the failure that agentic commerce exposes hardest, because an agent asks one question that spans all of them.

Where composable genuinely wins

Being fair to it, because the criticism is easy and the wins are real.

Multi-brand and multi-region at scale. One catalogue, one order system, several storefronts with different rules. Monoliths handle this badly and always have.

Genuinely unusual commerce models. If your business logic doesn't fit a platform's data model, you'll fight the platform forever. Composable lets you own the odd bit and buy the ordinary bits.

Existing systems you can't replace. An ERP, a PIM, a WMS that's load-bearing. API-first architecture is how you integrate rather than migrate, and that's often the right call.

Team autonomy at scale. Past a certain size, teams blocking each other on a shared monolith deployment is a real cost. Service boundaries fix it.

Notice that three of those four are organisational problems rather than technical ones. That's not a coincidence and it's the best argument for composable that exists.

Platform by platform: your realistic composable path

Shopify

Shopify's position is deliberately awkward for MACH purists. It's API-first and headless-capable, and it's a monolith. You can go composable around it: Storefront API for the frontend, your own services for anything Shopify won't model, checkout staying native.

That last part is the whole trick. Keeping Shopify's checkout means keeping the PCI scope, the fraud handling, the payment integrations and the conversion work. Most of what makes a composable checkout expensive is exactly the stuff you'd be rebuilding.

Realistic composable-on-Shopify: headless storefront, external PIM if your catalogue justifies it, external search if merchandising needs it, everything else native. That's a defensible architecture and it costs a fraction of a full composable build.

WooCommerce

Nobody markets composable WooCommerce and it's structurally one of the more composable things available, because WordPress is a plugin architecture and Woo exposes REST and GraphQL over everything.

The honest limitation is operational rather than architectural. Plugin quality varies enormously, the update path is manual, and the person who wrote the integration usually isn't around when it breaks. Composable Woo works when you have an engineering team. It falls apart when you have an agency on four hours a month.

Magento and Adobe Commerce

Adobe has been pushing composable hard, and Adobe Commerce is genuinely API-complete with a mature GraphQL layer. The commercially important detail is where the agentic layer lives. Agent Orchestrator sits inside Adobe Experience Platform, and Adobe's own announcement describes it working across Real-Time CDP, Experience Manager, Journey Optimizer and Customer Journey Analytics^[10]. Every one of those is a separately-licensed Adobe product.

So the agentic capability is not something an Adobe Commerce licence gets you. Adobe restated the direction at Summit in April 2026 with CX Enterprise^[16], and the shape is consistent: the AI layer is a separate commercial conversation.

Which is worth sitting with. Additional licensing for the AI layer, inside a supposedly all-in-one enterprise suite, is a fragmentation cost appearing in exactly the place composable was meant to eliminate it.

Magento merchants also carry the PWA Studio question, since Adobe stopped actively developing it in 2024 in favour of Edge Delivery Services^[11].

BigCommerce

The most credibly API-first of the hosted platforms, and it's positioned that way deliberately. Catalyst as the storefront, a genuinely complete API, and the ability to run headless without leaving the platform.

The consideration is ecosystem depth rather than API quality. Catalyst is MIT-licensed and well built and sits at 242 GitHub stars^[12], which tells you something about how many other teams have hit your problem before you.

Fully composable

commercetools, Elastic Path, Fabric, or an open-source backend like Medusa, which sits at 35,290 stars with 21 commerce modules^[13]. Real option, real cost, and the open-source route removes the licence while keeping every other line of the bill.

The composable readiness scorecard

Score yourself. Under 6 and you're not ready, whatever the deck says.

Question	Score 1 if yes
Two or more engineers comfortable with APIs, events and CI/CD, on staff[4]	1
A named owner for integration maintenance, with time allocated	1
Revenue above £15M	1
A specific requirement your platform demonstrably cannot meet	1
Multiple storefronts or regions from one catalogue	1
Budget for implementation at 2–4× the licence cost[4]	1
An existing ERP or PIM that must stay	1
Tolerance for a 5–10 month build before value[5]	1
A plan for what happens when a vendor is acquired or shuts down	1
Board-level agreement that this is a multi-year commitment	1

What agentic commerce does to the composable argument

This is the newest input and it genuinely changes the calculation, in a direction that surprised me.

Google's Universal Commerce Protocol launched at NRF on 11 January 2026 with Shopify, Etsy, Wayfair, Target and Walmart as co-developers^[14], and the Agentic Commerce Protocol maintained by OpenAI and Stripe sits at spec version 2026-04-17^[15].

Both require one coherent answer per product: available, priced, deliverable by this date, returnable until that date. One answer. Not one from your PIM, another from your OMS and a third from your storefront cache.

A monolith gives you that by construction. A composable stack gives you that only if someone built the aggregation layer deliberately, and in a lot of composable stacks nobody did, because no human-facing surface ever needed it all at once.

This is precisely why Futurum's respondents name AI as the consolidation driver^[2]. It isn't that composable is wrong. It's that composable without a data layer was always half a strategy, and agents are the thing that finally makes the missing half visible.

What to do this week

1. Count your vendors, and count your integrations. Integrations, not vendors, is the number that predicts pain.
2. Score the readiness table above. Honestly. Under 6 is a no.
3. Ask any composable vendor for total year-one cost, not licence. The licence is 20-40% of it^[4].
4. Work out who maintains integrations when they break. By name, with time allocated.
5. Write down the specific thing your current platform can't do. If you can't name one in a sentence, that's your answer.
6. Check where your AI layer is licensed. On Adobe it runs on Experience Platform, not on your Commerce licence^[10].
7. Ask whether anything in your stack can answer "available, priced, delivered when, returnable until when" in one call. If not, that's the gap agents will find^[14].

The takeaway

Composable isn't in retreat. Composable maximalism is, and the data showing it comes from a survey of 830 IT leaders where best-of-breed procurement fell to 20.7% while composable architecture adoption kept climbing^[2][1].

The stance I'd defend: for a mid-market brand with a single DTC storefront, picking your own search vendor doesn't buy four years of differentiation. It buys an integration you maintain forever. Composable earns its cost when the problem is organisational scale or a genuinely unusual model, and not when the problem is that the current platform feels dated.

What's the specific thing your platform can't do? If you had to say it in one sentence to a CFO, what would it be?

Sources

1. Composable comes of age in the Gartner DXP Magic Quadrant. MACH Alliance, citing Gartner. Note: published by the industry body that promotes composable.
2. 41% of Firms Plan App Consolidation; Best-of-Breed Procurement Falls to 20.7%. The Futurum Group, 1H 2026 Enterprise Software Decision Maker Survey, 830 IT decision-makers.
3. MACH Alliance. Accessed 22 July 2026.
4. Composable Commerce Platform Selection Scorecard 2026. Branch8. Agency-published; they sell implementation work.
5. Ecommerce Replatforming Cost Index 2026. Elogic Commerce. Agency-published; they sell replatforming work.
6. commercetools Pricing: What Enterprises Actually Pay. VendorBenchmark. Buyer-side aggregator, not vendor-published.
7. Shopify Pricing (UK). Shopify. Accessed 22 July 2026.
8. BigCommerce Pricing. BigCommerce. Accessed 22 July 2026.
9. API versioning. Shopify developer documentation. Accessed 22 July 2026.
10. Adobe Launches Adobe Experience Platform Agent Orchestrator. Adobe newsroom, March 2025.
11. PWA Studio FAQ. Accessed 22 July 2026.
12. bigcommerce/catalyst. GitHub. Star count read 22 July 2026.
13. medusajs/medusa. GitHub. Star count read 22 July 2026.
14. Under the Hood: Universal Commerce Protocol (UCP). Google Developers Blog, January 2026.
15. Agentic Commerce Protocol specification. Maintained by OpenAI and Stripe. Spec version 2026-04-17.
16. Adobe Redefines Customer Experience Orchestration Vision in the Agentic AI Era. Adobe newsroom, April 2026.
17. Sunsetting Shogun Frontend: What it Means for Stores. Shogun, 23 March 2023.