Skip to content
WhittleOSWhittleOS
← All guidesProblems5 min read

Platform risk, counted rather than warned about

Everyone warns about building on someone else's platform and nobody says how often it is actually fatal. Across 706 candidates our gate killed, platform dependency named 19.8% of them — and it is the only check we softened on purpose.

By Boris Binyaminov · ·

Candidates killed
706, across 23 real runs
Named platform risk
140 — 19.8%
Where it was the only reason
15
Checks that can be soft
One, and this is it

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% of them. It is also the one check we deliberately made survivable, and those two facts belong in the same sentence.

Where it ranks among ways to die

The gate asks 10 questions of every sourced candidate. One of them is "Does it survive if one platform changes its rules?". Here is what actually did the killing:

No documented problem behind it438
Too much hands-on support187
Depends on a platform140

The three most common causes of death across 706 killed candidates, measured 2026-09-06. Third is not first — which is the honest place to start an article about platform risk.

Third. Behind "no documented problem behind it" by a factor of three, and behind support load. That ordering is worth sitting with, because the discourse has it the other way round: platform risk gets the essays and the cautionary tales, while the thing that actually kills most ideas is that nobody could find anyone complaining about the problem.

Two honest notes on that chart before it gets quoted. The counts come from 23 real runs, all on the founder's own accounts — this measures how our gate behaves, not how a market behaves. And an earlier recording of this measurement said ninety-one runs, because it counted stub-mode synthetics that kill nothing at all; the kill counts reproduced exactly and the denominator was wrong, which is the kind of error that survives review because the interesting number looked right.

Why we made it the soft one

Here is the part that runs against our own instincts as a product that likes saying no.

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 the checks — Shopify apps, Discord monetization tools, Upwork tooling, IDX and MLS widgets, Instagram schedulers. Look at what they have in common. Every one of them reaches a buyer through a marketplace.

Now 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.

Platform risk plus anything else

125

Still dead. A platform dependency next to a second failing check is a real verdict, and the softening does not reach it.

Platform risk and nothing else

15

Revived — carried forward carrying the kill reason as a flag, ranked last, never displacing a candidate that cleared every check.

The split that makes the softening narrow rather than generous. Both numbers come from the same measurement as the chart above.

{fig.softFilter} is the only one of the 10 checks that can do this, and the rule it follows is deliberately mean: platform dependency costs a candidate its rank, not its life. A revived candidate keeps its kill reason on the page, is pinned to the bottom of the ranking, and fills leftover capacity only. It can never push out an idea that passed everything.

What it refuses to do

It does not invent a score. The triage prompt tells the model to rate a killed candidate zero, so a revived one carries no honest merit signal — and rather than manufacture one, the pin stays at zero and the ranking partitions on the flag before it looks at any score at all. That sounds like a detail. It is the difference between "we softened a rule" and "we quietly promoted the ideas the rule was there to catch".

And it does not override you. If your profile says platform dependency is a dealbreaker, the hard kill stands. The softening exists because a constraint you stated pushed you toward marketplaces; it switches off the moment you state the opposite.

How to read your own platform exposure

Three questions, and none of them is "is this risky".

What exactly does the platform give you — distribution, data, or the product? Losing distribution is survivable and slow. Losing the API your feature is made of is not, and it is fast.

Is there a version of this that keeps the customers when the platform changes? Not a fallback in principle — a specific one. An email list you own, an export path, a second channel already sending someone. The check is whether you can name it.

Is the dependency the price of your only viable channel? If the honest answer is yes, platform risk is not a reason to stop. It is a reason to price the risk in, ship the fallback early, and treat the platform's terms page as something you read on purpose rather than after an email.

The short version

  • Third, not first. Platform risk named 19.8% of the candidates our gate killed; missing evidence of a problem killed three times more.
  • 15 of 140 died of platform risk alone, and reading those was what changed the rule — all of them marketplace-shaped, which is where an async-only founder gets pushed.
  • It is the single soft check of 10: sole platform risk survives with a flag and the worst rank; platform risk plus anything else stays dead, which is 125 of them.
  • The softening never invents merit and never overrides a founder who says the dependency is a dealbreaker.
  • Measured on 23 real runs, all our own accounts. It describes our gate, not a market.