Total Cost of Ownership: Composable Commerce vs Monolithic Platforms
When a commerce director presents a composable commerce business case to their CFO, the conversation often stalls at the same point. Implementation costs are higher upfront. The vendor landscape is more fragmented. The licensing model is unfamiliar. Against the known quantity of an existing Salesforce Commerce Cloud or SAP Commerce contract, composable architecture looks expensive on first inspection.
That first inspection is misleading, and this article explains why.
Total cost of ownership analysis is the right framework for evaluating a commerce platform decision, but it must be applied rigorously — accounting for costs that monolithic vendors systematically exclude from their pricing conversations and benefits that composable architecture delivers across a three-to-five-year horizon. This article provides that framework, with worked financial examples, honest analysis of when monolithic platforms are genuinely more cost-effective, and a clear picture of where composable commerce, and specifically Elastic Path, delivers superior return on investment.
This is not a technology article. It is a financial one.
Why Platform Decisions Get the Economics Wrong
Most commerce platform decisions are made by comparing the wrong numbers. A direct comparison of Year 1 licensing costs between a monolithic vendor and a composable stack almost always favours the monolith. The monolith’s licence bundles a long list of capabilities into a single line item. The composable stack appears as multiple vendors, each requiring negotiation and integration.
The comparison fails for two reasons.
First, it counts costs that composable incurs directly while ignoring equivalent costs that are embedded in the monolith’s licence. The monolith charges for capabilities you do not use. It forces you to upgrade all components when you only need to update one. It locks you into infrastructure contracts with embedded margins. These costs exist whether or not they appear on a vendor invoice.
Second, it ignores the cost of capability gaps. Monolithic platforms reach a ceiling of what they can deliver without expensive customisation. Every feature your business needs that falls outside the platform’s native capabilities generates one of two costs: custom development within the monolith’s constrained architecture (expensive, slow, and fragile) or forgoing the capability entirely (an opportunity cost that rarely appears in the TCO model).
Rigorous TCO analysis starts by identifying all costs on both sides of the comparison — not just the visible ones.
The Full Cost Inventory: Monolithic Platforms
Licensing and Platform Fees
Enterprise monolithic platforms — Salesforce Commerce Cloud, SAP Commerce Cloud, Adobe Commerce (formerly Magento Commerce) — are not cheap. Salesforce Commerce Cloud pricing is typically structured as a percentage of gross merchandise value (GMV), commonly 1-3% for B2C deployments, with minimum annual fees that can reach GBP 200,000 for mid-market accounts before a single line of custom code is written. SAP Commerce Cloud and Adobe Commerce use a hybrid model of base licence plus infrastructure fees, with enterprise contracts typically running GBP 150,000-400,000 per year depending on transaction volume and feature tiers.
These fees escalate. Monolithic vendors renegotiate contracts at renewal, often applying annual increases of 5-10% that are buried in the terms and conditions. GMV-linked pricing means that as your business grows, your platform costs grow proportionally — even though the marginal cost of processing an additional order on a cloud-native platform is effectively zero.
Upgrade and Maintenance Cycles
This is the hidden cost that most TCO models underestimate. Monolithic platforms release major versions on a roughly annual cycle, and those upgrades are not optional. Falling behind on upgrades means losing security support, compatibility with payment processors, and access to newer platform features. Staying current means re-testing the entire customised platform with every release.
For a mid-market organisation running Salesforce Commerce Cloud or Adobe Commerce with meaningful customisation, a major platform upgrade typically costs GBP 50,000-150,000 in development and QA effort per cycle. This is money spent not to add features, but simply to stay current. Over a five-year period, upgrade costs can equal or exceed the original implementation budget.
Customisation Costs and Technical Debt
Monolithic platforms are designed for the median use case. Any requirement that deviates from the vendor’s intended use cases — complex B2B pricing, multi-level approval workflows, deep ERP integration, non-standard checkout flows — requires customisation within the platform’s architecture. That customisation is expensive to build because it must work within the monolith’s constraints, and expensive to maintain because every upgrade must be tested against the customised code.
The phenomenon of upgrade-breaking customisations is so common that platform vendors have terminology for it. Salesforce calls heavily customised implementations “over-customised.” Adobe warns against modifying core Magento code. The warnings are well-founded, but the business requirements that necessitate customisation do not disappear simply because the platform was not designed for them.
Over a five-year period, customisation maintenance typically costs 20-40% of the original development investment per year. For a GBP 500,000 implementation, that is GBP 100,000-200,000 annually in maintenance, much of which produces no new functionality.
Vendor Lock-In Premiums
Once deeply embedded in a monolithic platform, the cost of switching creates leverage for the vendor at every contract renewal. Organisations that have invested GBP 500,000-2,000,000 in a platform implementation do not switch vendors lightly. Monolithic vendors are aware of this.
The lock-in premium manifests as above-market licence renewal rates, resistance to commercial concessions, and slower feature development for capabilities that serve a niche use case. If the platform’s native search is inadequate for your requirements, the cost of replacing it is bounded by the fact that search is tightly coupled to the monolith’s data layer. You may be forced to pay for third-party search integration on top of a licence that already includes a search engine you cannot use.
Infrastructure Costs
Monolithic platforms have specific infrastructure requirements that create costs beyond the licence fee. On-premises or private cloud deployments (still common for SAP Commerce) require dedicated infrastructure that is over-provisioned for peak load, standing idle during off-peak periods, and managed by internal teams or contracted managed service providers. Even SaaS deployments often include infrastructure tiers that bundle compute, storage, and bandwidth at margins that exceed commodity cloud pricing.
The Full Cost Inventory: Composable Commerce
Component Licensing
Composable commerce incurs licensing costs for each component in the stack: the commerce engine (Elastic Path), headless CMS, search (if using a third-party service), payment processor, and any other specialised services. These are real costs that must be included in the TCO model.
However, there are important differences from monolithic licensing. First, you only pay for the capabilities you use. If you do not need the monolith’s built-in loyalty engine, you do not pay for it. Second, each component licence is independently negotiable and replaceable. If a better search provider emerges, or if a component’s pricing becomes uncompetitive, you can replace that component without rebuilding the entire stack. Third, cloud-native composable components scale with usage — you pay for what you consume, not for a fixed capacity ceiling.
Implementation Costs
Composable commerce implementations typically have higher initial development costs than monolithic deployments. The integration work between components, the custom frontend development, and the orchestration layer all require investment that a monolithic platform’s admin interface replaces with configuration.
A realistic implementation budget for a composable commerce project of moderate complexity — a B2B buyer portal with ERP integration, or a multi-channel B2C deployment — runs GBP 250,000-600,000. This is broadly comparable to a complex monolithic implementation, though the distribution of spend is different: more on integration and frontend, less on platform configuration.
Ongoing Development and Operations
Here is where composable commerce’s financial advantage becomes significant. Because services are independently deployable, changes to one component do not require regression testing of the entire platform. Teams working on MACH architectures report 40% faster feature release cycles compared to monolithic equivalents. This productivity gain compounds over time, reducing the cost per feature and increasing the velocity at which the business can respond to market requirements.
Infrastructure costs for cloud-native composable services scale with demand rather than fixed tiers. Elastic Path, for example, runs on managed cloud infrastructure where you are not paying for idle capacity during off-peak periods.
Three-Year TCO Model: Worked Example
The following comparison models a mid-market B2B commerce operation with GBP 20 million annual online revenue, complex pricing requirements, and two ERP integrations. Figures are indicative ranges based on market-representative costs.
Monolithic Platform (Salesforce Commerce Cloud)
| Cost Category | Year 1 | Year 2 | Year 3 | 3-Year Total |
|---|---|---|---|---|
| Platform licence (GMV-linked, ~1.5%) | £300,000 | £315,000 | £330,750 | £945,750 |
| Initial implementation | £450,000 | — | — | £450,000 |
| Annual platform upgrade | — | £75,000 | £80,000 | £155,000 |
| Customisation maintenance (25% of impl.) | £60,000 | £112,500 | £112,500 | £285,000 |
| Infrastructure (embedded in licence) | — | — | — | £0 |
| Integration maintenance | £30,000 | £35,000 | £35,000 | £100,000 |
| Annual total | £840,000 | £537,500 | £558,250 | £1,935,750 |
Composable Commerce (Elastic Path)
| Cost Category | Year 1 | Year 2 | Year 3 | 3-Year Total |
|---|---|---|---|---|
| Commerce engine licence (Elastic Path) | £60,000 | £63,000 | £66,150 | £189,150 |
| Supporting services (CMS, search, etc.) | £30,000 | £31,500 | £33,075 | £94,575 |
| Initial implementation | £480,000 | — | — | £480,000 |
| Component upgrades (minor, independent) | — | £15,000 | £15,000 | £30,000 |
| Ongoing feature development | £80,000 | £80,000 | £80,000 | £240,000 |
| Infrastructure (cloud-native, usage-based) | £18,000 | £20,000 | £22,000 | £60,000 |
| Integration maintenance | £25,000 | £20,000 | £20,000 | £65,000 |
| Annual total | £693,000 | £229,500 | £236,225 | £1,158,725 |
Three-year saving with composable: approximately GBP 777,000 (40% lower TCO).
The Year 1 costs are comparable. The divergence emerges from Year 2 onwards, driven primarily by the elimination of upgrade cycles, reduced customisation maintenance costs, and the removal of GMV-linked licence escalation.
Five-Year TCO Model: The Compounding Advantage
The five-year model is where composable commerce’s financial case becomes compelling for any organisation with meaningful growth ambitions. As online revenue grows, GMV-linked monolithic pricing escalates. As requirements evolve, customisation debt on the monolith accumulates. As the market changes, the inability to selectively replace components becomes an increasingly expensive constraint.
Monolithic Platform (continued to Year 5)
| Year | Platform Licence | Upgrade Costs | Maintenance | Other | Annual Total |
|---|---|---|---|---|---|
| Year 4 | £347,288 | £85,000 | £120,000 | £35,000 | £587,288 |
| Year 5 | £364,652 | £90,000 | £120,000 | £35,000 | £609,652 |
| 5-Year Total | £3,132,690 |
Composable Commerce (continued to Year 5)
| Year | Licence Fees | Dev & Ops | Infrastructure | Other | Annual Total |
|---|---|---|---|---|---|
| Year 4 | £104,801 | £80,000 | £24,000 | £20,000 | £228,801 |
| Year 5 | £110,041 | £80,000 | £26,000 | £20,000 | £236,041 |
| 5-Year Total | £1,623,567 |
Five-year saving with composable: approximately GBP 1,509,000 (52% lower TCO).
These figures do not include the revenue impact of 40% faster feature release cycles. For an organisation generating GBP 20 million in online revenue, the ability to deploy a new pricing model, a new channel, or a new buyer experience weeks rather than months faster has measurable commercial value. Nor do they include the value of strategic optionality — the ability to replace any component without rebuilding the stack.
The Composable Advantage: Selective Component Replacement
One of the most financially significant advantages of composable commerce is the ability to replace individual components without incurring a full replatforming cost. This is not a theoretical benefit. It has direct financial implications for every commerce director planning their five-year technology roadmap.
Consider a mid-market organisation running Elastic Path with a headless CMS that has served its purpose but is now limiting content personalisation capabilities. In a composable architecture, replacing the CMS is a bounded project: implement the new CMS, migrate content, reconnect the existing API integrations, and deploy the updated frontend data-fetching layer. The commerce engine, search, pricing, and checkout are untouched.
The equivalent exercise on a monolithic platform — replacing the tightly coupled CMS with a headless alternative — requires custom development against the platform’s internal APIs, potential interference with the upgrade path, and regression testing of the entire platform. A bounded GBP 50,000-80,000 project in a composable stack becomes a GBP 200,000-400,000 undertaking within a monolith.
Elastic Path’s expanding capabilities reinforce this advantage. Native semantic search, AI-powered product discovery, and hosted storefront options mean the platform itself is evolving, with new capabilities available without the upgrade burden that monolithic platforms impose.
When Monolithic Platforms Are More Cost-Effective: An Honest Assessment
Trust in a financial analysis depends on its honesty about limitations. There are scenarios where monolithic platforms are genuinely more cost-effective than composable architecture, and it is worth being clear about them.
Simple B2C Catalogues with Standard Requirements
If your commerce operation has a straightforward B2C product catalogue, standard checkout flows, no complex pricing requirements, and a small development team, the integration overhead of a composable stack is a cost without a corresponding benefit. A well-configured Shopify Plus or Salesforce Commerce Cloud deployment may serve your requirements for less total investment than a composable architecture that requires ongoing technical expertise to operate.
The composable advantage scales with complexity. Below a certain threshold of business requirements, the architecture’s flexibility is not needed, and its integration costs are not justified.
Organisations Without Technical Maturity
Composable commerce requires a technically capable team. Not in terms of headcount, but in terms of capability: developers comfortable with API integration, cloud infrastructure, modern JavaScript frameworks, and CI/CD pipelines. Organisations that primarily manage their commerce platform through an admin interface, without an in-house development function, may find the operational requirements of a composable stack challenging.
This is a solvable problem — specialist implementation partners like McKenna Consultants provide the expertise that bridges the gap — but it is a legitimate consideration when modelling the total cost, including the internal resource requirements of each approach.
Short Planning Horizons
The composable TCO advantage builds over time. In a two-year planning horizon, the Year 1 implementation cost and early operational investment may not be fully offset by the savings that accumulate from Year 2 onwards. If your planning horizon is genuinely short — due to a planned business sale, a merger, or a strategic pivot — the upfront investment in composable architecture may not deliver its full financial return within your window.
For most organisations with a three-to-five-year commerce technology strategy, however, the composable TCO case is compelling.
The Developer Productivity Factor
The 40% faster feature release cadence that MACH architectures enable is not an abstract claim. It reflects the operational reality of independent service deployment versus monolithic release management.
On a monolithic platform, deploying a change to the search ranking algorithm requires a full regression test of the entire platform before it goes to production. On a composable stack, the same change — deployed to the search service alone — requires testing only the search service and its API contract with the frontend. The scope of testing is bounded by the service boundary, not the size of the entire application.
For a development team billing at GBP 600-900 per day (typical for UK commerce developers), the productivity gain translates directly into cost efficiency. A team that can deliver 40% more features within the same budget is, in effect, delivering a 40% reduction in the cost per feature. Over a three-year programme of commerce development, that compounding productivity advantage is worth hundreds of thousands of pounds.
It also has a strategic dimension. Faster feature releases mean faster market response. Composable commerce teams can test a new pricing model, a new channel experience, or a new buyer workflow in weeks. Monolithic teams plan the same change for the next release cycle.
Building the Business Case for Your Organisation
The worked examples above are illustrative. Your organisation’s TCO model will differ based on your current platform, online revenue, customisation depth, team structure, and growth trajectory. Building a credible business case requires modelling your specific numbers, which in turn requires an accurate assessment of current costs — many of which are embedded in existing contracts and not immediately visible.
The key inputs to gather before building your TCO model are:
- Current platform licence fees, including all annual escalation clauses
- Development time spent on platform upgrades and maintenance over the past three years
- Integration costs, including both initial build and ongoing maintenance
- Infrastructure costs, including any embedded in the platform contract
- Development velocity: how many features were delivered in the past 12 months, and how much of that team’s time was spent on maintenance rather than new development
With these numbers in hand, the TCO comparison typically tells a clear story. For organisations with complex requirements, meaningful online revenue, and a planning horizon of three or more years, composable commerce delivers materially lower total cost of ownership than monolithic platforms — while simultaneously providing the technical foundation for capabilities (agentic commerce, AI-powered search, multi-market expansion) that monolithic platforms cannot deliver without prohibitive customisation costs.
How McKenna Consultants Can Help
McKenna Consultants is a UK-based composable commerce consultancy specialising in Elastic Path implementations for complex B2B and multi-market deployments. We have delivered composable commerce projects for organisations including Norgren and Astrak, and we bring direct experience of the implementation costs, integration patterns, and operational requirements that are essential for credible TCO modelling.
If you are preparing a business case for composable commerce investment, or evaluating whether to renew your existing monolithic platform contract, we can provide a structured TCO assessment based on your specific situation. That assessment will tell you honestly whether composable commerce is the right financial decision for your organisation — and if it is, what a realistic implementation and operating model looks like.
Contact McKenna Consultants to discuss your composable commerce evaluation. We are experienced in working with CFOs, commerce directors, and CIOs at the business case stage, and we can provide the financial rigour that turns a technology preference into a boardroom-ready investment case.
