Every enterprise marketplace platform RFP produces a headline number - the annual licence fee. It is presented as the cost of the platform. It is not. In most enterprise deployments, the licence fee represents less than 20% of the total expenditure across the first three years of operation. The remaining 80% is distributed across implementation services, infrastructure, internal resource, ongoing maintenance contracts, and in some cases the accumulated cost of a growing headcount to operate workflows the platform was never designed to automate.
This article breaks down what enterprise marketplace implementation actually costs, where the money goes, and what a different architecture model means for total cost of ownership.
The number vendors quote
Enterprise marketplace platform vendors quote a headline licence fee. For the dominant players, this starts at £75,000-£90,000 per year for a mid-enterprise engagement and scales upward with transaction volume (GMV-based models) or user count. The number is real, but it is the entry point to the cost structure rather than the cost structure itself.
Procurement teams that treat the licence fee as the primary cost variable typically end up with budget overruns of two to five times the original estimate. This is not unusual or exceptional - it is the normal pattern for enterprise marketplace implementations built on platforms that depend on systems integrators and ongoing professional services.
The systems integrator problem
Platforms like Mirakl are designed to be configured by specialists. The platform provides a framework; the systems integrator provides the expertise to make it operational. This is not a bug - it is an intentional architectural choice. The platform captures the licence revenue; the SI partner ecosystem captures the implementation revenue. Both parties benefit from deep SI dependency.
For the operator, the consequences are significant. SI implementation scopes for enterprise Mirakl deployments typically run £500,000-£2,000,000+ depending on integration complexity, custom workflow requirements, and storefront build. This is before the platform is operational. After go-live, ongoing configuration changes - adding a new supplier onboarding workflow, adjusting commission rules, modifying catalogue enrichment logic - typically require the same SI, at day-rate cost that runs into six figures annually.
The SI dependency also affects speed. Every change that requires SI involvement has a delivery lead time. Organisations that want to respond quickly to commercial opportunities find that the operational cadence of their marketplace is constrained by the availability and velocity of a third party.
It is worth noting that SI dependency is a feature of platform architecture, not an industry standard. Platforms built as infrastructure - where operational logic is handled autonomously rather than configured - do not require ongoing SI involvement because the automation layer manages what the SI would otherwise handle.
Beyond the SI engagement, several cost categories are routinely underestimated or omitted from initial platform budgets.
Infrastructure and hosting. Platforms that are deployed on the operator's cloud infrastructure add hosting, compute, database, and DevOps cost. Depending on transaction volume and architecture, this adds £30,000-£80,000 annually. Platforms that include infrastructure in their fee - where the hosting is managed by the vendor - eliminate this line entirely.
Internal project resource. Enterprise implementations require internal project management, technical architecture review, data mapping, and user acceptance testing. For a 12-month implementation, this represents one to three internal FTEs for a significant portion of the year - a real cost even if it does not appear as an external invoice.
Operational headcount. Platforms that handle catalogue enrichment, order routing, exception flagging, and supplier communications manually require staff to do that work. At 50 active suppliers, this might be one person. At 200 suppliers, it is typically three to five people. At 500 suppliers, it becomes an operational team. Platforms with agentic automation collapse this headcount to near zero regardless of supplier count.
Licence escalation. GMV-based pricing means the platform cost increases automatically as the marketplace grows. Operators who negotiate on the entry fee often discover that year-three costs are materially higher than year-one costs, precisely because the marketplace has been successful.
Delayed commercial return. An 18-month implementation timeline is a cost. The transaction volume, supplier relationships, and customer data that would have existed had the marketplace been live 12 months earlier are genuinely lost. This is not captured in a TCO model but it is real commercial value that does not exist.
The GMV pricing trap
Gross Merchandise Value pricing is the dominant model for legacy enterprise marketplace platforms. It aligns vendor revenue with operator success - the vendor earns more as the marketplace grows. This sounds reasonable until operators model it across a three-to-five year horizon at realistic growth rates.
At £50M annual GMV with a 0.2% GMV fee (a typical structure at enterprise scale), the annual platform cost is £100,000. At £150M GMV three years later, that cost is £300,000 - a 200% increase in platform cost for the same infrastructure. The operational value of the platform has not tripled; the transaction volume has. The platform is capturing a percentage of value it did not create.
Operators that accept GMV pricing should negotiate hard on the rate and model the cost at the top end of their projected GMV range, not the midpoint. The rate that seems reasonable at entry looks very different when the marketplace succeeds.
What a no-SI model looks like
Infrastructure-first platforms like Esetrix are designed so that SI involvement is unnecessary. The platform arrives pre-integrated: all eight modules share a single data layer, supplier onboarding is managed through a self-serve portal, and the agentic automation layer handles the operational logic that SI teams would otherwise configure.
The practical result is a deployment timeline measured in weeks rather than months, and an ongoing cost structure that does not include external professional services. Changes to workflow logic, supplier tier structures, commission rules, and catalogue enrichment parameters are made by the operator's team through the platform configuration, not by raising a ticket with an SI.
This model is not appropriate for every organisation. Operators with very specific legacy system integration requirements, or those who have existing contractual SI relationships they need to utilise, may still prefer a platform that accommodates SI involvement. But for operators who want to move quickly and control their own roadmap, the no-SI model is structurally different in cost and operational autonomy.
Side-by-side cost comparison
The table below compares a representative mid-enterprise deployment of Mirakl against Esetrix across the cost dimensions that compose total cost of ownership over three years.
| Cost component | Mirakl (typical) | Esetrix | Note |
|---|---|---|---|
| Annual platform licence (Yr 1) | £75k-£120k | Flat fee (contact) | Mirakl scales with GMV |
| SI implementation fees | £500k-£2M+ | £0 | Esetrix needs no SI |
| Internal project resource (Yr 1) | £80k-£200k | £20k-£40k | Lighter spec / shorter duration |
| Infrastructure / cloud hosting | £30k-£80k/yr | Included | Included in Esetrix |
| Post-live SI retainer (Yr 2-3) | £80k-£250k/yr | £0 | Ongoing config changes require SI |
| Operational headcount added | 2-5 FTE | 0-1 FTE | Agentic automation reduces headcount |
| Approximate 3-yr TCO | £1.5M-£5M+ | Fraction of Mirakl TCO | Varies by GMV and scope |
These numbers are based on typical engagement patterns and publicly available information about enterprise marketplace implementation costs. Individual deployments vary, and operators should run their own model using vendor-specific quotes. The purpose of this comparison is not to produce a precise figure but to illustrate the order-of-magnitude difference between SI-dependent and infrastructure-first deployment models.
Questions to ask every vendor
Before finalising a platform selection, ask each vendor the following questions and request answers in writing:
1. What is your typical all-in implementation cost for a company of our size, including SI fees, internal resource, and infrastructure? Any vendor unwilling to provide a range is unable to help you build an accurate business case.
2. What percentage of your enterprise clients go live without a systems integrator? If the answer is zero or near zero, budget accordingly.
3. What does our platform cost at 5× our current projected GMV? Any GMV-based pricing model should be stress-tested at the top of your growth range.
4. What changes after go-live require SI involvement? The answer reveals how much operational control you will retain after deployment.
5. Can we speak with three clients at our scale about their actual implementation and operational cost? Vendor-supplied references at the right scale are the most reliable cost data available.