Composable DXP: How to Choose MACH Vendors Without Creating a Frankenstack
Composable architecture trades vendor lock-in for integration ownership. Choose deliberately, or you inherit a stack nobody can operate.
Composable architecture solves a real problem. Monolithic suites force you to accept a mediocre search engine because it ships with a good CMS, and every upgrade becomes a coordinated risk event. Unbundling fixes that — and hands you a new job: you now own the integration surface between every component, forever.
The organisations that succeed with composable DXP treat vendor selection as the smaller half of the decision. The larger half is deciding who owns the seams.
What MACH actually commits you to
MACH — microservices, API-first, cloud-native, headless — describes a stack where each capability is independently deployable and consumed over APIs. The implication most business cases omit is that no vendor owns the end-to-end experience anymore. When a product page renders slowly, the cause could be the CMS, the search service, the commerce API, the personalisation call, or your own orchestration layer. Without an orchestration and observability strategy, mean time to resolution rises sharply.
The decision: composable or suite
| Signal | Choose composable | Choose a suite |
|---|---|---|
| Requirements | Exceed suite capability in two or more domains | Met by 80 percent of suite functionality |
| Engineering capacity | Permanent platform team available | Agency-supported, limited internal engineering |
| Time to value | Can absorb six to twelve months | Needs launch within a quarter |
| Change frequency | Frequent experimentation across channels | Stable, mostly editorial change |
| Touchpoints | Web plus apps, kiosks, partners, agents | Primarily web |
Hybrid is legitimate and common: keep a suite as the core while unbundling one or two capabilities where the gap is genuinely painful, typically search or commerce.
Component selection criteria that matter
Feature grids are the least useful part of vendor evaluation because every vendor scores well on their own grid. Evaluate operational reality instead.
- API quality and limits. Rate limits, payload shapes, pagination behaviour, and webhook reliability determine whether the integration is pleasant or a permanent tax.
- Latency under realistic load. Test with your catalogue size and query complexity, not the demo dataset.
- Content modelling flexibility. Can the model express your actual editorial structures, including reusable components and localisation, without workarounds?
- Editorial experience. Preview, scheduling, workflow, and rollback. If merchandisers and editors cannot see their work before publishing, they will route around the platform.
- Exit cost. Bulk export fidelity, including relationships and assets. A vendor without a credible export path is lock-in wearing composable branding.
- Vendor durability. Funding stage, customer references at your scale, and roadmap transparency.
Design the orchestration layer deliberately
The single most common composable failure is letting the browser orchestrate. When the client calls six services per page, latency compounds, failures cascade, and every vendor change becomes a frontend release.
Instead, put a thin orchestration layer between components and presentation. Its job is to compose view-shaped responses, apply caching per data type, degrade gracefully when a non-critical service fails, and normalise vendor differences so swapping a component does not ripple into the frontend. Keep business logic out of it — orchestration that becomes a second application is how organisations end up with a monolith they also have to maintain.
Integration ownership and governance
Write down, before contracts are signed, who owns each seam, what the contract is, and how it is versioned. Then enforce three practices: a shared content and data model documented in one place; contract tests running in CI against every vendor API you depend on; and an incident runbook that names the first responder per component. Composable stacks fail operationally far more often than they fail architecturally.
Total cost of ownership
Licensing is the visible cost and rarely the largest. Model over three years: component subscriptions, orchestration and frontend build, permanent integration maintenance, observability tooling across vendors, and the internal cost of vendor management — five vendor relationships need real coordination effort. Composable typically costs more in years one and two and pays back through avoided replatforming and faster capability swaps in years three and beyond.
Sequencing a migration
Unbundle one capability at a time, starting with the component whose limitation costs the most today. Run old and new in parallel behind a feature flag, migrate content with a scripted, repeatable pipeline rather than a one-off effort, and validate SEO parity — URLs, rendering, structured data — before every cutover. Only decommission the legacy component after a full reporting cycle at parity.
Frequently asked questions
What is a composable DXP?
A digital experience platform assembled from best-of-breed services — headless CMS, search, commerce, personalisation, identity — integrated through APIs rather than delivered as one monolithic suite.
Is composable always better?
No. It wins when requirements exceed suite capability and permanent integration engineering is funded. Otherwise a suite delivers faster and cheaper with fewer operational surfaces.
What is the biggest risk?
Unowned integration seams. Vendors are individually reliable; the failures happen between them, and without named ownership and contract tests nobody notices until customers do.
How many components is too many?
As a rule of thumb, if you cannot name the on-call owner for every component, you have more components than the organisation can operate.