DEV Community: Boris Binyaminov

Platform risk gets the essays. In our own kill data it comes third.

Boris Binyaminov — Wed, 16 Sep 2026 15:44:46 +0000

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

Your customer count is the easy half. The support hours next to it decide your price floor.

Boris Binyaminov — Wed, 16 Sep 2026 13:20:58 +0000

Target divided by price, rounded up. That is the whole first answer, and every article on this question spends a page defining monthly recurring revenue instead of giving it. The second answer is the one that decides things.

One honest edge in that arithmetic first, because it is the kind of case a calculator usually gets wrong. A ONE-TIME price has no answer here at all — there is no recurring revenue to divide — so the function returns nothing rather than a confident zero. A zero would be a wrong answer wearing the costume of a computed one, and it is the sort of thing a user will screenshot.

Now the part that makes the first number misleading. At 5000 a month you need 173 customers at 29, or 51 at 99. What makes the count feel useful is that it sounds achievable. That feeling is where the mistake lives.

Put support next to it. Take 15 minutes per customer per month — one short email, or a fraction of a call you are not taking — and the two numbers move in OPPOSITE directions. Every step down in price multiplies the customers, and every extra customer adds support you personally owe.

At 29 that is 173 customers and 10 hours a week of support before you have built or sold anything. At 49 it is 103 customers and 5.9 hours — a real share of the week, and survivable. The bands are calibrated to one person's week rather than a company's: past eight hours a week, support is not a cost of the business, it is the job.

So the answer to how many customers do I need is not a number. It is: at or above 49, about 103 of them. Below that the count stops being the binding constraint and your calendar becomes it.

Three levers, and they are not equal. Cut the minutes — support load is linear in them, so halving 15 halves every hour column and moves the floor down a price step; this is the only lever that helps at every price at once. Raise the price, which is the fastest single move and the one most solo founders refuse. Or lower the target, because 5000 is a choice rather than a law.

The last thing the division quietly hides, and it is the one that changes plans. You do not need 103 customers in TOTAL. You need 103 at the same time. It is a level to be held, not a finish line to be crossed.

At 5 percent monthly churn you lose one in twenty every month, so holding 103 means signing roughly 6 new customers a month before you have grown by a single seat. At 29 the same churn means replacing about 9 a month, on top of the 10 hours of support you already owe. That is why the cheap rows are worse than they look.

What the arithmetic does not know, stated because a calculator invites more confidence than it has earned: it assumes every customer costs the same, it ignores billing and refunds and the occasional bug that eats a Saturday, and it assumes the customers exist and can be reached — which is the question that actually kills most ideas and that no calculator can answer.

Both calculators, no signup: https://whittleos.com/guides/how-many-customers-do-i-need

Our scoping tool refuses in 4 of the 7 states it can be in, and that ratio is not a tuning choice

Boris Binyaminov — Wed, 16 Sep 2026 10:31:47 +0000

What should I build first is the most answerable-looking question in the whole process, which is why every tool answers it on the spot. Ask a chatbot and you get a feature list in twenty seconds. The list will be reasonable. It will also be a plan for building the wrong thing efficiently, if nobody has established that anyone wants the thing.

So our scoping analysis checks a precondition before it will produce anything, and in most of the states you can be in, it refuses.

The gate, and why it is countable

The gate is not a judgement call. It reads the most recent verdict the idea already carries and maps it, and because the map covers every value the verdict enum can take plus the case where there is no verdict at all, the set of states is finite and countable: 7 of them, of which 4 refuse and 3 open.

That ratio is not a tuning choice. It is where the map's fall-through lands, and the fall-through was pointed at refusal deliberately — anything the gate does not positively recognise as validated is treated as unvalidated, so a verdict nobody has taught it about fails closed rather than quietly unlocking a build plan.

Notice which states are in the refused set. Not just the killed idea: the idea nobody has evaluated at all, which is the state every idea is in on the day you have it, and the held one, where the evidence was inconclusive. Inconclusive is not a soft yes.

What the refusal refuses to do

What the refusal does is the part I would argue for hardest. It does NOT produce a smaller scope, a lean version, or a scope with a warning on top. The scope comes back empty with a paragraph explaining why. A tool that hedges has produced the scope, and you will build from it, because the scope is the concrete artefact and the caveat is a sentence.

The six fields, derived rather than listed

When the gate does open, 6 fields are mandatory — and that list was derived rather than transcribed: each was blanked in turn and fed to the invariant that guards real output. Two of them are the ones nobody asks a chatbot for.

A condition for quitting. A scope with no stated point at which you abandon it is not a plan, it is a wish with tickets — and the useful property of that condition is that it has to be written before you are emotionally invested, which is exactly now.

And an explicit not-building list. The features you are cutting are the ones you will otherwise re-add in week three, one reasonable decision at a time. Naming them converts a hundred future arguments with yourself into one decision you already made.

The honest edge of that second guarantee, since we publish the derivation: the contract asks for more than one non-goal and the invariant only refuses an EMPTY list, so a scope with exactly one non-goal passes. The intent is stricter than the enforcement, and a page claiming a guarantee should say precisely where it stops.

Two rules the parser enforces first

Two rules the parser enforces before any invariant runs. Every must-have feature has to name the job it serves — a feature with an empty job does not parse at all, confirmed by handing the parser exactly that. It earns the strictness because name the job is the question a feature list cannot survive: features that exist because a competitor has them have nothing to write there. And the build window is bounded, with accepted values running from 1 to 4 weeks. There is no option for a scope that takes a quarter, because a first version you cannot finish inside 4 weeks is the product, and you have gone back to building on faith.

It also does not re-decide the idea: the projection is neutral, decision unknown, score a placeholder 50. A tool that let a scoping pass raise an idea's score would be laundering enthusiasm into evidence.

The gate table and both field lists: https://whittleos.com/guides/what-to-build-first-mvp-scope

We published our scoring weights, and the useful number is the 4x leverage gap

Boris Binyaminov — Wed, 16 Sep 2026 06:52:47 +0000

Search how to build a weighted scorecard and every result stops in the same place: choose criteria, assign importance, multiply, sum. All correct, and all of it ends exactly where the decision starts. Which criteria. What importance.

Why weights stay unpublished

That gap is not an accident of writing. Publishing weights commits you — a reader can say you priced trust twice as high as margin and I think you are wrong, and can notice when your own scores do not follow your stated rules. Unpublished weights cannot be argued with, which is comfortable and useless.

Ours, and the one that counts for nothing

Ours: 7 categories that carry weight, plus one that is rated, displayed, and contributes nothing. The top three are tied at 20 each rather than one dominating, because no ordering between reachability, channel and economics survived contact with real ideas, so none was invented.

Evidence that the problem is real is deliberately weighted below all three. That reads wrong until you see what it prevents: excellent evidence of a problem nobody can be reached about is still a bad business, and weighting evidence at the top would let a well-documented dead end outscore a reachable one.

The decision that matters more than the weights

The implementation decision that matters more than the weights: the model rates each area, and code computes the total. If a language model hands back its own overall number it can talk itself into a pass, and no amount of prompt discipline makes that auditable.

What a point is actually worth

What a point is worth, which is what a published rubric actually buys. Take an idea rated 7 everywhere except distribution, which comes back 3 — a decent product nobody can be reached about, the most common shape there is. The total is 62.

Spend three rating points on the weak area and you get 70: a gain of 8, and the grade moves. Spend the same three on the lightest category and you get 64, a gain of 2, and nothing about the decision changes. The heaviest area carries 4 times the leverage of the lightest.

That ratio is the entire practical value of publishing a rubric. Without it you cannot tell the expensive fix that moves a verdict from the satisfying one that does not, and work goes where it feels productive rather than where it counts.

The honesty clause

The honesty clause, because a published rubric obliges it. The arithmetic is fixed and repeats; the ratings underneath are model judgements sampled at temperature one, so the same idea run twice can score differently. A total is a reading, not a measurement — and anyone claiming otherwise is describing their arithmetic and hoping you hear it as their whole system.

One more thing we had to get right: uncertainty is not a middling score. A category the model cannot judge does not average to the middle. It is marked low-confidence, and enough of those push the verdict to hold rather than letting a confident-looking total emerge from several shrugs.

Every weight, the worked example and the grade bands: https://whittleos.com/guides/how-to-score-a-business-idea

At 30 support minutes per customer, 100 customers is 11.5 hours a week

Boris Binyaminov — Tue, 15 Sep 2026 19:12:45 +0000

Support is the thing founders plan to deal with later. For one person it is not a cost line, it is a constraint on what the product can BE — and unlike almost everything else you want to know before building, it is decidable now, because the answer follows from the workflow you are describing rather than from usage data you do not have.

The scale runs the other way

One design decision to get straight first, because it is the only part of this analysis a reader can read backwards. The scale runs the other way. Every other mode scores upward, and this one inverts, because the good outcome is the small one: the best verdict maps to 85 and the worst to 25.

Say it plainly: a HIGH verdict is bad news. If you skim one number off this and it is high, you have found the problem, not the endorsement. We render that chart from the projection the scorecard actually uses, so the polarity on the page cannot drift away from the polarity in the product — which is the only real defence against a chart that silently inverts after a refactor.

The instruction pushing back

The contract also carries an instruction pushing the other way, and it is worth knowing about: the estimate must not be over-pessimistic, on the stated grounds that over-pessimism wrongly kills viable ideas. A gate tuned to find support problems everywhere would find them everywhere, so it is explicitly told not to reach.

The arithmetic

Now the arithmetic that makes this decide the product's shape rather than its cost structure. Fix the customer count at 100 and sweep the minutes each one takes per month. 5 minutes is 1.9 hours a week. 30 minutes is 11.5 hours a week. 60 minutes is 23 hours a week.

That is the whole argument. At 30 minutes per customer per month — one real exchange, not a crisis — support alone is more than a day of every week at a customer count most solo products would call a good start.

The two distinctions that decide it

Two distinctions do the work of deciding which row you are on, and neither needs usage data. First, is a ticket DEFLECTABLE: can docs, onboarding or the product itself answer it, so you fix it once — or does it need you, every time, forever. Second, customisation risk: does everyone get the same product, do some clients need a setting nobody else uses, or does each client need work only you can do. The third rung is the definition of an agency, and nobody arrives there on purpose. You arrive one accommodating yes at a time.

Where this ranks, measured

Where this ranks among ways an idea dies, measured rather than asserted: across 706 killed candidates on 23 real runs, hands-on support load was named in 187 of them — 26 percent, second only to the missing documented problem. Measured on 2026-09-06, on our own accounts, so it describes our gate rather than a market.

The practical consequence for a design decision: every feature that needs explaining is a recurring cost priced in your weeks, and the cheapest support work is the kind you do once in the product rather than every time in an inbox.

The sweep and both ladders: https://whittleos.com/guides/will-my-saas-be-support-heavy

At $9/month you need 334 customers and 19.2 support hours a week

Boris Binyaminov — Tue, 15 Sep 2026 15:22:53 +0000

Pricing advice for small software is either enterprise value-pricing theory or charge more as a slogan. The solo founder's question is a different one: not what this is worth, but whether there is any price at which ONE PERSON can carry the customers that price requires.

The verdict that does not exist

The analysis returns 3 verdicts, and the first thing to notice is what is missing. There is no verdict for too high. That is not an oversight — it is not the failure mode a one-person product has.

The middle verdict is the one to sit with. Acceptable means you can charge enough and have NOTHING SPARE — no room for a bad month, a refund run, or the customer who turns out to cost four times the average. Most first prices land there and get read as a pass.

The contract also defines a low-ticket trap: an idea structurally stuck below roughly 19 a month, or 100 once. When that is true the analysis says so and names the reason rather than proposing a price it does not believe in.

Where most pricing writing cheats

Be clear about what that threshold is, because this is where most pricing writing cheats. It is a JUDGEMENT WRITTEN INTO A PROMPT, not a measurement — a line drawn by a person who had seen enough one-person products to have an opinion. On its own it is worth very little, and you should treat any pricing floor you read anywhere the same way.

What makes it interesting is what happens next to arithmetic that knows nothing about it. Sweep the price ladder at a 3000 target and 15 support minutes per customer per month: 9 a month is 334 customers and 19.2 hours a week; 19 is 9.1 hours; 29 is 104 customers and 6 hours.

The 2 rows at or below the pricing threshold are exactly the 2 rows in the heavy support band. Past eight hours a week support is not a cost of the business, it is the job — and that is where the pricing line falls, without either half having been told about the other.

The limit, stated before anyone else states it

Now the honest limit, because it is the kind of coincidence people quote badly: BOTH HALVES ARE OURS. A prompt rule agreeing with a calculator we also wrote is internal consistency, not external validation. What makes it worth publishing is only that the two were authored separately for different purposes, and neither was tuned to the other. If you take the number and drop the sentence, you have taken the wrong half.

Two rules that keep the output honest

Two implementation rules that keep the output honest. Comparators cite a source or say UNKNOWN — a competitor's price is a fact about the world, and inventing one is the single most common lie in pricing research, convincing precisely because plausible prices are easy to generate.

And the model is NOT ALLOWED to do the arithmetic. The customers-needed calculation is explicitly forbidden to it and done in code instead. That is not a performance decision. A division is the one part of this with a right answer, and handing a right answer to something that samples is how you get a page of confident numbers that do not add up.

One more closed set worth copying: what a price may be anchored to. 5 options, and the first three — revenue, hours saved, a bill cut — are the ones you can defend in a sentence to a stranger. If the honest answer is status, you are selling a feeling, which sometimes works and never works predictably for one person with no brand. If the answer is other, the price is a guess wearing a rationale.

The ladder and both rules: https://whittleos.com/guides/how-to-price-a-micro-saas

We sourced 3430 startup ideas and kept 93. The filter is the product.

Boris Binyaminov — Tue, 15 Sep 2026 13:49:47 +0000

Generating ideas is cheap and getting cheaper. Eliminating them is not. A list of startup ideas is an unsorted queue with no discard policy, which is why it only ever grows.

Step one, sourcing

Stop generating and start reading. The unit of input is a documented complaint: one sentence naming who has the problem, plus a link you can open. Without the link it is something you thought while reading, not something you found.

Step two, elimination

A fixed set of questions in a fixed order, cheapest-to-establish first. The ORDER is the engineering decision — a question answerable in an afternoon of reading belongs ahead of one that needs a month of building, regardless of which is more interesting.

The measurement

From one sweep on 2026-06-04: 30 markets, 3430 candidates sourced, 93 finalists. That is 2.7%, roughly one candidate in 37. A pipeline that keeps most of what it generates is not a filter.

Two failure modes, and the first one is ours

Reading the score as a measurement. The total is computed in code from a fixed rubric, so the arithmetic is reproducible — but the ratings feeding it are sampled, so the same idea can move a few points between runs. It is an ordering. The number invites you to read it as a measurement anyway.

Gathering evidence after choosing. Evidence found before you commit narrows the field. Evidence gathered afterwards confirms the choice you already made, and you will always find it.

What we would do differently

Widen breadth before deepening one market. Raising the cap inside a single market saturates, because the stock of real documented complaints there runs out; a new market opens a fresh pool. We measured that the expensive way.

The full write-up, with the run behind every number, is at https://whittleos.com/guides/startup-ideas