The ecosystem tax: dozens of partners, not thousands

A platform with a few dozen delivery partners instead of thousands isn't a badge of exclusivity — it's a concentration risk. When the pool of firms and engineers who know your commerce stack is small, replacing an underperforming integrator, staffing a second team, or surviving a lead architect's departure all get harder and slower. The fix isn't avoiding good niche platforms; it's budgeting to insource the operating knowledge early.

Why does ecosystem size read as operational risk?

When you license a platform you are really buying two assets: the software, and the population of people who can implement and run it. The second one almost never makes the evaluation scorecard, yet it governs most of what happens after go-live. Reviewers feel it even when they can't price it. On Capterra, one of the top cons flagged against a well-regarded, open, .NET-based B2B commerce platform is stated with the brevity of someone who has lived it:

Yet small eco system

Take that at face value. A third-party partner tracker counts roughly a dozen named partners as of August 2025, and the vendor's own directory sits in the same low-dozens range. Set that against the thousands of consulting partners in the Salesforce ecosystem, or the many thousands of certified consultants across SAP's partner network, and the gap is on the order of a hundredfold. That figure isn't vanity — it is the size of the labour market you can hire, fire and re-bid inside.

Partner headcount is only the visible layer. A thin ecosystem is also a thin market for the things partners produce: pre-built connectors, battle-tested integration patterns, a community answer waiting for the error you hit at 2am. On a mature platform many of those arrive as plug-and-play parts; on a niche, code-first one they are bespoke engineering, billed by the hour, and each hour deepens your dependence on the few people who have solved it before. Scarcity compounds — fewer partners means fewer reusable assets, which means more custom work, which means the operating knowledge ends up living in even fewer heads.

What happens when your bus factor is one SI?

Bus factor is the number of people who can walk out before the work stalls. In a deep ecosystem it is comfortably large; in a thin one it collapses to a single systems integrator, and sometimes to a single lead architect inside that integrator. Every operational lever you assumed you had quietly loses travel:

None of this is hypothetical. We have watched a delivery slip a full quarter not because the platform was weak, but because the one architect who understood a custom pricing module changed employers, and there was no second firm to phone while a replacement ramped. It is the same failure shape as when a single field app becomes the weakest link in an otherwise sound stack: the danger isn't the average component, it's the one nobody else can pick up. A thin partner market turns that from a component-level worry into a programme-level one, because the person who can pick it up may not exist on the open market at all. Ramp time for a genuinely new hire on an unfamiliar, code-first stack is measured in months, not weeks, and for those months your only real option is to pay the incumbent whatever the renewal asks.

Isn't a smaller ecosystem sometimes an advantage?

Honestly, yes, and it's worth saying plainly because the trade is real. A vendor with a dozen partners tends to know each of them by name. Escalations reach engineers who actually wrote the code, feature requests aren't lost in a queue behind ten thousand louder customers, and the roadmap is close enough to touch. For a focused build that is a genuine asset, and the closeness is part of why teams choose these platforms in the first place. The trap is mistaking that intimacy for redundancy. Vendor attention protects you on day one; it does nothing for you the morning your integrator loses its account team, gets acquired, or simply prices the next statement of work like the only supplier in the room — the same single-source dynamic that makes consumption pricing overshoot its budget once switching costs are baked in.

Where the diagnosis points

The direction, kept to a single paragraph because a problem this structural doesn't have a tidy checklist: treat the platform as something you will eventually operate yourself, and price the insourcing from day one rather than discovering it mid-incident. In practice that means a named internal owner shadowing the SI from the first sprint, source and deployment pipelines you hold rather than rent, and a hiring plan that assumes you cannot buy the skill on demand. It is the same discipline behind knowing exactly what your integration bill already adds up to — you cannot insource what you have never fully counted. When we scope a build-and-operate pilot, the transfer of operating knowledge is a named deliverable, not a hope.

Over the next year this constraint gets sharper, not softer. As more brewers move to leaner, composable commerce stacks to escape suite lock-in, the binding limit quietly migrates from software licences to the people who understand the software — and that market does not scale as fast as the technology does. The teams who come out ahead won't be the ones who picked the largest ecosystem; they'll be the ones who assumed, on the day they signed, that the ecosystem might one day be just them.