Most ecosystem platforms are designed with one participant in mind. A retailer builds a trade-in platform for its own stores. A manufacturer builds a portal for its distributors. The first participant is understood deeply because the business is the first participant.
The second participant is where the model usually breaks.
That failure is rarely a technology failure. It is a design failure that becomes visible only when another organisation, with its own commercial interests, its own systems and its own customers, begins to use the platform.
The first participant problem
When a single organisation designs a multi-party platform, it naturally optimises for its own workflow. Permissions, data visibility and commercial terms are set around what that organisation needs to see and control.
This is not a mistake in the narrow sense. The founding participant is paying for the platform and knows its own process exactly. The problem is that its requirements get encoded as assumptions rather than as configuration, and assumptions are expensive to reverse once data and integrations exist.
What the second participant actually needs
A distributor does not want the manufacturer seeing its margin. A repair partner does not want its turnaround times visible to a competitor. A marketplace does not want to reconcile stock twice.
Beyond confidentiality, a participant joining a platform usually needs six things.
- Its own customers to remain its own. Customer ownership, consent and communication rules must be explicit before integration rather than negotiated after launch.
- Control over its own pricing. Unless the commercial model requires price harmonisation, participants need to price independently within agreed rules.
- Operational independence. Joining should not require replacing systems that already work.
- Predictable settlement. When money moves, participants need to know the calculation, the timing and the dispute route.
- A credible exit. Data export, notice periods and what happens to live transactions.
- Evidence of return. A measurable benefit that exceeds the cost of integration, within a timeframe the participant can defend internally.
Most of these are commercial and governance requirements, and all of them are architectural, because the platform either supports them by design or needs a rebuild to add them.
Three failures that repeat
Entitlements designed as an afterthought. Access is granted by role, where the role maps to the designing organisation's departments rather than to participant types with commercial interests. Adding a participant then requires rebuilding permissions.
No shared definition of the core record. A device, an order or an asset has a different shape for each party. Integration becomes a mapping exercise per participant, and mapping errors show up as commercial disputes.
Participation without incentive. The platform is presented as a benefit to the operator. The participant is asked to change its own operations to feed the operator's system, with no return that outweighs the disruption.
Entitlements are architecture, not configuration
The most common second-participant failure is a permissions model built on internal roles. Internal roles describe what a colleague may do. Participants need a model of participant types, data scopes and commercial entitlements that survives new joiners, new categories and competing participants.
| Design decision | Single-organisation design | Multi-party design |
|---|---|---|
| Identity | Internal user accounts | Verified organisation accounts with individual users attached |
| Permissions | Role per department | Participant type, data scope and record-level conditions |
| Data visibility | Full internal visibility | Field-level visibility with commercial confidentiality by default |
| Pricing | Central price list | Participant-owned pricing within platform rules |
| Settlement | Internal accounting | Defined calculation, timing, statements and dispute process |
| Change | Internal release | Versioned contracts and notice before rules change |
Designing the multi-party model first is slower at the start and considerably faster by the fifth participant, because each new participant is configured rather than engineered.
The shared record problem
Participants will not agree on the shape of an asset, an order or a customer, and they should not be asked to. What they can agree on is a canonical identifier and a small set of shared attributes, with each participant's own representation mapped to it.
Two things make this workable. A published data contract for the shared record, versioned so changes are visible before they break integrations. And an event history, so that when two participants disagree about the state of a transaction, the sequence of changes is available rather than reconstructed from memory.
Commercial mechanics belong in the design phase
Pricing, commission, settlement, invoicing and reversals are usually treated as reporting concerns until the first dispute. In a multi-party platform they are core.
Specify early: how a price is formed, who may change it and when; how commission is calculated and on what base; when settlement runs and what a statement contains; how refunds and reversals are handled; who bears the cost of a failed transaction; and how a dispute is raised, evidenced and resolved.
A settlement calculation that cannot be reproduced from stored data will be disputed, and the dispute will be expensive.
Onboarding friction decides adoption
Participants judge a platform by the effort required to join and the time to first transaction. The recurring friction points are integration requirements that assume the participant's systems look like the operator's, unclear data requirements, manual verification steps with no visible progress, and commercial terms that arrive after technical work has begun.
Offering a simple path and an integrated path, with a sandbox that behaves like production, converts far better than a single deep integration that only suits large participants.
Governance and exit
Every ecosystem platform needs answers to questions that are not technical: who admits participants, who may change the rules, how changes are notified, who arbitrates disagreements, who owns the data and what happens when the operator exits.
Exit deserves particular attention. A platform that participants cannot leave safely is difficult to join, and a platform whose participants cannot export their data will be treated as a commercial risk by any serious counterparty.
What to design first
The order matters more than the technology choice.
- Define the participant types and what each one gives and receives.
- Define the shared record and who may see which part of it.
- Define the commercial mechanics: pricing, commission, settlement, entitlement.
- Define governance: admission, rule changes, disputes and exit.
- Validate the model with a paper walkthrough for each participant type, including the awkward cases.
- Only then design the interfaces and the platform.
Platforms that follow this order tend to extend from two participants to ten without a rebuild. Platforms that begin with the workflow of the founding organisation usually require a rebuild at the second.
Technical patterns that make extension cheaper
An entitlements service that other services call, rather than permission logic repeated in each module. Tenant-aware data partitioning with the participant as a first-class dimension. Event-driven synchronisation for state changes, with idempotent interfaces for the retries that always follow. Versioned data contracts. A sandbox that mirrors production behaviour. And observability per participant, because a complaint that the platform is slow is always about one participant's specific integration.
This is the core of how we approach ecosystem development, and it is why we treat entitlements and commercial mechanics as architecture rather than configuration. It also shapes how we build marketplace platforms and connect them to participants' existing systems through API integration.
How Sardo Group can help
We design and build multi-party platforms as platform development, covering participant identity, entitlements, shared records, settlement and integration with the systems participants already run.
If you are extending an internal platform to external participants, or building a marketplace or trade-in network from the start, the useful first conversation is about the second participant.
Start a project or contact us to discuss the model.
Frequently asked questions
What is an ecosystem platform?
A software platform operated by one organisation but used by several independent organisations that transact or exchange information through it.
Why do multi-party platforms fail at the second participant?
Because the first was designed as an internal workflow. Permissions, data visibility and commercial terms reflect the operator's needs, and cannot accommodate a participant with its own interests without redesign.
Should entitlements be configuration or architecture?
Architecture. Participant types, data scopes and commercial entitlements need a first-class model that other services call, rather than permission logic written into each module.
How do you keep participants' commercial data confidential?
Field-level visibility with confidentiality as the default, participant-scoped tenancy, and explicit rules about which shared attributes each participant type may read.
How long does it take to extend a platform to external participants?
It depends on the existing architecture and how much of the participant model already exists. A scoped assessment of entitlements, shared records and settlement is usually the first piece of work.