Where the 90/10 rule comes from
A rule of thumb has been making the rounds in build-vs-buy circles this year: buy roughly 90% of your software, build only the 10% that's genuinely differentiated or missing from the market. It shows up across enterprise reports, founder newsletters, and vibe-coding guides, almost always stated the same way and almost never checked against anything. It's a clean number. Clean enough that it's worth actually testing rather than repeating.
What 200+ real verdicts actually show
This register carries an independent build-vs-buy verdict for every one of the 200+ real SaaS apps it reviews — not a ratio decided in advance, a specific judgment made per app, per feature set. Add them up and the real split is nothing like 90/10: 20% BUILD IT, 44% BORDERLINE, and 36% JUST PAY. The build side is roughly double what the popular rule suggests. More importantly, the rule has no room at all for a middle category — and that middle category turns out to be the largest single group in the data, not a rounding error.
The biggest single category isn't build or buy — it's both
BORDERLINE is the plurality verdict on this register, ahead of BUILD IT and JUST PAY individually. Apps like Miro, Loom, and Airtable all land here for the same underlying reason: real, substantial parts of the product are genuinely buildable in a weekend, and a real, specific part isn't — a rendering engine, a sync problem, a licensing detail. A binary ratio has nowhere to put 'the achievable half is worth building and the rest isn't,' which is arguably the most common real-world shape a build-vs-buy decision actually takes, not the exception the rule implies.
Even most JUST PAY apps aren't hard to build
The most counterintuitive number in the data: apps that land on JUST PAY still average 78.9 out of 100 on this register's own buildability score — not far behind the 89.9 average for BORDERLINE apps, and comfortably above the midpoint. If 'just pay' meant 'too hard to build,' that number should be low. It isn't, because most JUST PAY verdicts aren't about difficulty at all. They're about a specific, nameable moat — the five real categories this register has written about in detail: network effects, licensed content, regulated infrastructure, specialist rendering engines, and integration ecosystems. Reading through which moat you're actually up against is a more useful exercise than checking your idea against a ratio.
Notion: 88 out of 100, and still just pay
Notion is the cleanest single illustration of why score and verdict measure different things. Its components — a block editor, a database view, real-time collaboration — score 88 out of 100 on this register, higher than the average BORDERLINE app. The verdict is still JUST PAY. Not because the code is hard; a personal knowledge base with the same core features is a genuinely achievable build. Because a workspace's actual value comes almost entirely from other people already using it, and a perfectly-coded clone with zero existing users has none of that value on day one. Score measures the parts. It was never meant to measure the network.
A better question than a ratio
The 90/10 rule isn't wrong so much as too blunt to be useful at the level most build-vs-buy decisions actually happen — one specific tool, one specific team, one specific weekend. A fixed ratio can't tell you which bucket your idea falls into; it can only tell you the ratio was popular. What actually holds up, checked against 200+ real examples: ask whether the thing you're replacing has a specific, nameable moat, not whether it clears an arbitrary percentage. Describe what you're actually trying to build and get a verdict for that exact thing, not an average.