Platform risk gets plenty of warnings and very few measured denominators. We can publish one about our own gate, because we kill candidates for it and keep the receipts.
Across 706 rejected candidates, platform dependency was named in 19.8 percent of them. Which puts it third, behind the missing documented problem at 438 and hands-on support load at 187.
Third, not first, is the honest place to start an article about platform risk. The discourse has it the other way round: platform dependency gets the essays and the cautionary tales, while the thing that actually kills most ideas is that nobody could find anybody complaining about the problem.
A correction that belongs in the post rather than in a footnote, because it is the failure mode of every internal metric. An earlier recording of this measurement said ninety-one runs. It was counting stub-mode synthetics that kill nothing at all. The kill counts reproduced exactly and the denominator was wrong — which is precisely the kind of error that survives review, because the interesting number looked right and nobody re-derives the boring one.
Now the design decision. Of the 140 candidates that named platform risk, it was the ONLY reason in 15. We read those 15 rather than the ideas that passed: Shopify apps, Discord monetisation tools, Upwork tooling, property-listing widgets, Instagram schedulers. Every one of them reaches a buyer through a marketplace.
Put that next to a founder profile that says no calls, async only. For that founder a marketplace is frequently the one channel that delivers a paying customer without a conversation. So the gate was killing ideas for depending on the only distribution their own stated constraints left them.
The fix is one soft filter out of 10 checks, and the rule is deliberately mean: platform dependency costs a candidate its rank, not its life. Sole platform risk survives carrying its kill reason as a visible flag, pinned to the bottom of the ranking, filling leftover capacity only. Platform risk plus anything else stays dead, which is 125 of the 140.
The implementation detail that took a review to get right. Pinning the revived candidate's score to zero was NOT enough, because zero is a legal score for a candidate that genuinely passed, and the tie-break was input position. The ranking now partitions on the FLAG before it looks at any score at all.
And it refuses to invent merit. The triage prompt tells the model to rate a killed candidate zero, so a revived one carries no honest signal — rather than manufacture one, the pin stays and the partition does the work. That is the difference between softening a rule and quietly promoting the ideas the rule existed to catch.
It also does not override the user. If a profile says platform dependency is a dealbreaker, the hard kill stands. The softening exists because a constraint the founder stated pushed them toward marketplaces; it switches off the moment they state the opposite.
Measured on 23 real runs, all our own accounts, on 2026-09-06. It describes our gate, not a market.
The split, and the three questions to ask of your own exposure: https://whittleos.com/guides/platform-risk-startup
Top comments (0)