DEV Community: Boris Binyaminov

Nearly a third of our rejections came down to one reason. Check for it before you hire an agency.

Boris Binyaminov — Tue, 29 Sep 2026 07:38:08 +0000

We run a pipeline that sources startup candidates and then tries to kill them. Across 23 real runs it rejected 706 of them. What the rejections were for is useful to anyone about to hand a build to an agency, because the reasons cluster and almost all of them are answerable before a line of code exists.

The limits first, because they bound everything after. The 23 runs are our own two accounts and no customer data is in them, so this measures how our gate behaves rather than how a market behaves. The counts were taken on 2026-09-06.

The most common reason accounted for 438 of the 706: no problem found behind the idea. Precisely — no match in the corpus of public complaints we had collected, which is a statement about our sources as much as about the idea. The rest spread across support load, platform dependence, and the ordinary economics of one person running a product.

The figure that changed how I read the rest: on 31 percent of all rejections, that pain check was the ONLY reason recorded. Not a bundle of concerns — one structural fault, on its own, on nearly a third of them.

What to do with it before anyone quotes you. Take your own spec and try to fail it on three things: whether the problem is described in writing by someone who is not you, how many hours a week the thing costs to support once it works, and whether one platform's policy change can end it. A build contract answers none of the three.

The gate, the counts and the exclusions behind them: https://whittleos.com/guides/validate-before-hiring-an-agency

A grader that is pure code, and the three monotonicity rules that do the work

Boris Binyaminov — Fri, 18 Sep 2026 17:20:48 +0000

The standard answer to validating without interviews is: talk to customers. The useful version is narrower. You are not skipping the customer — you are changing what you collect from them. A conversation gives you an opinion you grade AFTER you have heard it. A number checked against a bar you wrote down first gives you something you cannot re-grade once you have seen it.

The problem with interviews is not the interview. It is that they are unfalsifiable in the hands of the person who wants the answer. You ask ten people whether they would pay, seven say something encouraging, and you now hold ten data points and the freedom to decide afterwards which of them counted. You will decide in the direction you were already leaning, because you wrote the questions and you are the one who has to abandon eight months of work if the answer is no.

That is not a discipline problem you fix by being more rigorous in the room. The bar moved because nothing was holding it in place. So put something in place: pre-registration. Write down what would count BEFORE the test runs — a number, a metric and a deadline — then run it and compare.

In our product that is not rhetorical. Validation plans emit machine-gradable criteria alongside the English ones, and the grader is pure code with no model call in it. It reads exactly 5 things, and that set is closed on purpose: a grader that cannot read a metric cannot grade it, and a criterion existing only as English prose is marked ungradable rather than quietly interpreted.

Three rules do the actual work, and each is a monotonicity decision rather than a feature.

A blank is not a zero. An unreported metric grades as not-reported, never as not-met. Collapsing those would make an empty form read as evidence the idea failed, and I did not measure it is not that. When every criterion comes back blank the whole outcome is ungradable and nothing moves.

The window runs one way. A criterion says reach N within D days. Reaching it faster passes; taking longer does not. A founder who needed thirty days to clear a fourteen-day bar produced a different result from the one the plan asked for, and letting it through deletes the only time-box in the loop.

And you cannot correct upward. Within one plan the report that counts is the weakest one filed: a worse number takes effect immediately, a better one leaves the earlier grade standing. The asymmetry is deliberate — a bar written in advance is worth nothing if the answer can be rewritten after you have seen how it graded.

Now the part where validation advice usually overreaches. A landing-page test that goes well is not proof the idea works. It is proof of some specific things and silence on others. In our scorecard the widest single metric can evidence 55 percent of it. The remaining 45 percent — support load, platform exposure, cash flow — a clean market test cannot reach at all.

And traffic on its own evidences 0 categories. A channel is proven when it delivers a PERSON, not when it delivers attention. That one is worth writing on the wall.

The worked plan in the piece publishes 4 criteria, of which the grader could grade 3, of which 1 was met — a partially-met outcome rather than a pass or a fail, because that is what the numbers actually support.

The template, the three rules and what a pass does not prove: https://whittleos.com/guides/validate-startup-idea-without-talking-to-customers

We ship a thing that judges startup ideas, and we could not answer whether it works

Boris Binyaminov — Fri, 18 Sep 2026 17:19:38 +0000

The problem: we ship a thing that judges startup ideas, and we could not answer whether it works. Not in the marketing sense — in the sense of never having run anything.

The design we settled on. Take companies whose stories are over, reduce each to the one-liner it could have been described by at founding, strip the name, and feed it to the live gate. The known ending and its public source sit in the table next to our verdict.

The scoring rule is the part worth stealing. Only a KILL counts as catching something. A HOLD or a pilot-first is the gate declining to decide, and counting those as saves is precisely the arithmetic that lets everything in this category call itself accurate.

Run on 2026-06-23 against 8 companies — 5 that really failed, 3 that really worked. Solo lens: 4 of the 5 flops killed, and 1 of the 3 successes killed as well. Funded lens: 2 of 5 flops, 0 successes. 3 rows were never killed by either lens.

Then we did not publish a percentage, and that decision is the piece rather than a caveat on it. Four separate defects, any one of which is enough.

The sample is small and hand-picked — chosen because the outcomes are known and famous, which is a selection rule with nothing to do with the population of ideas a user actually brings.

Hindsight leaks. The cases are anonymised, but a model may still recognise a famous shape. We cannot prove it did not, so we cannot treat a hit as clean.

The cells move. Each deal-breaker verdict is a five-sample supermajority vote, which is materially steadier than a single pass, but the weighted total is still one pass and a borderline row can drift a point or two between runs. It is a dated snapshot you can re-run, not a statistic.

And the verdict is founder-bound by design, which makes a single accuracy number incoherent rather than merely imprecise. The success we killed on the solo lens is a payments company: correctly killed for one person, correctly not killed for a team. Same one-liner, two right answers.

What I would tell anyone building an evaluation for a system whose output depends on who is asking. Decide what counts as a catch before you look. Keep every row that goes against you. And notice when your metric is asking a question your system does not answer — that was the real finding here, and it arrived last.

Full table, every row, including the flop that walked through both lenses: https://whittleos.com/guides/do-startup-idea-validators-work

Founder-market fit is usually discussed as credentials or as encouragement, and neither is answerable

Boris Binyaminov — Fri, 18 Sep 2026 17:18:23 +0000

Founder-market fit is usually discussed as credentials or as encouragement, and neither is answerable. We had to make it decidable, because in our product this is the one analysis where a fact about the FOUNDER can kill the idea outright. That is a strong thing for software to do, so most of the work went into what it costs.

The checks: 7 of them, and not one is about a CV. Can you build this, explain it, sell it, support it — and the one nobody expects, can you tell whether the output is any good. Plenty of buildable products fail there: you ship it, and you have no way to know whether what it produced was right, which means you cannot improve it and cannot defend it when a customer says it is wrong.

Each check grades in a vocabulary of 4, and the interesting boundary is not severity. It is whether learning is a plausible route at all. Weak closes with work. Foreign does not, and the honest response to foreign is a different idea rather than a longer study plan.

The aggregate lands on a ladder of 4 rungs whose consequences are computed rather than editorial, and the bottom rung is the one to read. It maps to a kill-filter failure, on a filter that is NOT one of the softenable ones — a platform dependency can be carried forward with a flag; this cannot.

So we attached a matching obligation: the bottom rung is required to cite a specific fact from the profile the user actually wrote. Not a vibe about the domain being hard — a named thing they said about themselves. The score it produces is 10, and it caps sales fit at 2.

The design decision I would defend hardest is the middle rungs. A mediocre fit does NOT subtract points across the whole scorecard. It puts a ceiling on the one category it has any business affecting and leaves the rest of the evaluation to the idea.

Then the part that beats the arithmetic. Alongside the score, the analysis returns a plain recommendation to keep the idea or drop it — and a drop recommendation lands on the same decision at every rung, including the top one. If the analysis has said in words that this is not your idea, letting a good numeric fit outvote it would be the numbers laundering a judgement.

Two failure modes this kind of analysis has, and the rules against them. It invents an attribute about you — our first live evaluation caught exactly that, checks asserting a founder had a low tolerance for something the profile never mentioned. The fix is an explicit grounding rule: only facts that literally appear in the idea or the profile, and an unstated attribute is unknown rather than scored against you. It is a convincing failure because an invented attribute sounds like a reasonable inference.

And it hands you a study plan made of nouns. Every gap has to survive one test — could I search for this and get a how-to — so Stripe billing webhooks passes and fintech compliance does not.

There is also a banned list in the output: no motivational language and no coaching, which means no mentors, no advisors, no get a co-founder. Those are real options, and none of them answers whether you can sell this thing next month.

The ladder, the two rules and the banned list: https://whittleos.com/guides/am-i-the-right-founder-for-this-idea

Sort your validation checklist by what an honest answer costs

Boris Binyaminov — Fri, 18 Sep 2026 14:52:17 +0000

Most validation checklists are a set of good questions in no particular order, which means people answer the interesting ones first. The order is worth more than the items.

The ordering rule: sort by what it costs to answer honestly — not by difficulty, and not by importance. An afternoon of desk research settles whether a problem is documented. It takes months to discover you cannot reach the buyer. So the cheap eliminations go first, and most ideas never reach the expensive questions at all.

The temptation runs the other way, and it is strong. The expensive questions are the interesting ones, they feel like real work, and answering them produces artefacts you can show people. Cost order is dull, and it is the only ordering that saves anything.

An implementation detail that caught us in review: there are two lists, not one. A candidate our own sourcing produced runs through 10 checks. An idea a user brings runs through 12. Publishing either one as the checklist was wrong in both directions.

The differences are not cosmetic. The user-idea list adds two the sourced one has no business asking — whether the thing pays for itself inside a year, and whether it could ever be sold or handed off — because those are questions about a business you intend to run.

And it deliberately does not apply the documented-problem anchor at all. There is no corpus to anchor a pasted idea against, so demanding one would kill every idea for the crime of arriving from outside. That asymmetry is the kind of thing a single shared list quietly gets wrong.

Now the part that makes it falsifiable. A checklist is a claim about what you would reject, so we counted one published run: 69 candidates, 36 dropped, each with the check that did it.

The most common cause of death is the absence of a documented problem — 21 of the 36, more than twice the next reason at 9. That is the first question on the list and the cheapest one to answer, which is the argument for cost order made by the data rather than by us.

The awkward number is in the same census. Those rows add to 57 reasons against 36 dead ideas, because most failed more than one check. The rows do not partition the drops, and a weak idea is usually weak in several directions at once — worth knowing if you were hoping that answering the one objection you have heard would rescue yours.

What a checklist cannot do is tell you an idea is good. Every check is a way of failing, and passing all of them means only that no known deal-breaker was found. That is a licence to run a real test, not a verdict.

Both lists in full, and the census: https://whittleos.com/guides/startup-idea-validation-checklist

A score with no published rubric has no floor to fall to

Boris Binyaminov — Fri, 18 Sep 2026 14:51:14 +0000

Ask a chatbot what it thinks of your startup idea and it will help you. That is the whole problem: helpfulness and judgement point in opposite directions, and only one of them was trained for.

Four mechanisms, none of them a defect. You told it the idea is yours, and a model completes the conversation it is in — the same text pasted as a competitor is doing this, what is wrong with it reliably produces a different answer, with nothing about the business having changed.

Agreeable answers were preferred during training. Humans rate the response that engages with their plan above the one that dismisses it. A sensible objective for almost every task, and a disastrous one for a go or no-go.

There is no cost to a false yes. A tool that encourages you loses nothing when you fail eight months later; a tool that kills your idea loses you today. The incentive is not disreputable, it just points away from the thing you wanted.

And scores drift upward when nothing anchors them. A number generated rather than computed from a published rubric has no floor to fall to — nothing says what a low rating looks like, so the model produces something plausible, and plausible-sounding is high.

The concrete instance, using our own idea so nobody has to trust our judgement about somebody else's. Same one-liner, 3 tools, on 2026-06-10.

A competitor returned 72 / 100 and PROMISING — excellent potential, among the top ideas we have seen. Our own adversarial mode returned 15 / 100, and our balanced check returned 0 / 100, short-circuiting on a deal-breaker rather than producing a score at all.

The limit of that evidence, stated before anyone quotes it back at us: one idea, one day, each tool once. It supports exactly one sentence — these were the outputs — and no claim about how any tool behaves in general. We publish the date so it can be re-run, which is the only thing that makes a sample of one worth publishing.

What actually separates a warm answer from a judgement, and none of it is tone — a tool can be blunt and still be flattering. Is the verdict bound to you, or is it a judgement about an idea in the abstract, which is a judgement about nobody. Are the weights published, so the number can be argued with. Can you open the evidence — a link that resolves to somebody saying the thing, not a list of sources considered.

The practical move if you get an encouraging answer: do not discard it, re-ask it in a frame that removes the flattery. Paste the idea as a competitor's product and ask what is wrong with it. Ask what would have to be true for it to fail, then check the cheapest of those yourself. If the verdict survives all of that it might be right. If it evaporates the moment the idea stops being yours, you learned what the first answer was measuring.

The table and the three properties: https://whittleos.com/guides/why-ai-says-your-idea-is-great

Two of the three refusal triggers are read from the founder, not the idea

Boris Binyaminov — Fri, 18 Sep 2026 14:50:02 +0000

Nobody needs to be told their idea is too broad. They arrive having noticed, and what they get back is the advice they already gave themselves: narrow it down, pick a niche, find your ICP. The decidable questions are different — what a narrowing must CONTAIN before it counts as one, and whether a narrowing exists at all for this founder.

So the analysis returns either a wedge or a refusal, and the refusal is the reason it is worth anything. The instruction is blunt: if every remaining slice still needs enterprise sales, still needs a conversation, or still runs through a platform the founder said no to, say so and do not invent a fake wedge.

That clause exists because inventing one is easy and rewarding. A plausible narrowing can be generated for any idea in a sentence, it reads like insight, and the founder cannot tell it apart from a real one until months have gone.

Note where 2 of the 3 refusal triggers are read from: the founder profile, not the idea. An idea that narrows beautifully for somebody who will get on calls has no wedge at all for somebody who will not — which is why a generic how-to-niche-down post cannot answer this, and why the profile is treated as binding rather than as a preference. A narrowing you refuse to execute is not a narrowing.

The contract asks for 7 things. 4 of them are mandatory, and here is how that list was produced rather than transcribed: each field was blanked in turn and fed to the invariant that guards real output. These are the ones it refuses to pass. If the rule changes, the list changes with it.

The other 3 are asked for and NOT policed, and we publish that too, because a page claiming an enforcement guarantee should say exactly where the guarantee ends.

The mandatory one people quietly skip is the explicit what-this-is-not. It is mandatory because a narrowing you have not stated as a CUT is not a narrowing, it is an emphasis — everything you kept in reserve is still in the product, still in the roadmap, and still in the conversation with the first customer who asks for it.

Second mandatory field worth its own paragraph: a NAMED buyer. Not small businesses, not teams — specific enough that you could go and find twenty of them this afternoon. The most common fake narrowing is a broad idea with a narrower adjective in front of it, and the named-buyer requirement is exactly what that fails.

The refusal branch is thinner than the wedge branch on purpose: it requires a reason and nothing else, checked the same way by building a refusal with every other field empty and watching the invariant let it through. A one-sentence no is a legitimate output, and knowing that before you receive one is better than assuming something broke.

What it deliberately will not do: re-score your idea. The projection is neutral — the decision comes back unknown and the score is a placeholder 50 — because a narrowing recommendation is not a verdict, and letting it produce one would mean scoring an idea nobody has evaluated yet. Narrow first, then judge the thing you intend to build.

And the suggested next step is constrained to async, scanned against 24 banned conversation phrases before you see it. Not a style preference: a validation step that requires a conversation is a step most people never take.

The derivation, both field lists, and the before-and-after: https://whittleos.com/guides/my-startup-idea-is-too-broad

A claim can never be promoted up the provenance ladder

Boris Binyaminov — Fri, 18 Sep 2026 11:44:32 +0000

The stock answer to where do I find customer problems is go read Reddit, which names a destination when the question is about a property. Destinations expire — an API closes, a forum goes private, a review site adds a login wall — and a method built on a list of sites expires with the list.

The property: somebody described it, in their own words, somewhere you can point at. Lose the third and you have a claim. Lose the second and you have a summary of a claim. Lose the first and you have your own hypothesis wearing a citation.

So the data model is a ladder of 5 provenance tiers, and the rule that makes it mean anything is that a claim can never be promoted UP it. A search snippet is real evidence that a page exists and says something; it is not evidence of what the whole page says. Anything grounded in a snippet stays capped at that tier however convincing the summary reads.

That rule is the entire product decision. Tools that collapse these tiers are not being sloppy — the collapse IS the feature, because a promoted claim reads better than a labelled one.

Why it needed a shared vocabulary rather than a convention: five hand-maintained copies once described the same tier three different ways, and one page rendered two of them at once. Now every surface imports one map.

Reachability has exactly 3 mechanisms, and each has a limit that decides what you may honestly quote from it. A search API returns results for a generated query — a snippet is not a page. Our own reader fetches a listing page and extracts entries — gated by that site's robots rules per fetch, and skipped when they say no. A documented public API, called directly.

Two consequences that cut against us, and both belong in the post rather than in a footnote.

Robots rules decide reachability and we obey them. A site that says no is skipped, and whatever it knew is absent from the run. That is a real hole in coverage, and the honest response is to say so rather than to route around it.

And the best evidence is often the least reachable. Long complaint threads behind logins, support forums that render client-side, private communities — the places people are most candid are exactly the places a fetcher cannot go. Anyone claiming complete coverage of where customers complain is describing a product that does not exist.

What one run actually read: 41 sources consulted, 24 pages opened and read in full, 56 problems recorded, of which 32 carry a link you can open — 57 percent. The other 24 are marked unverified rather than deleted, and that distinction is the method.

The gap between sources consulted and pages read is the snippet tier doing its job rather than a shortfall. And the 3 hosts that run reached are not a recommendation list — they are where one run's generated queries happened to land, for one niche, on one day.

If you are doing this by hand: keep the URL rather than the summary, record the date, mark what you inferred, and count what you could not reach. A search that returned nothing is a finding; a site that refused you is a hole whose shape is worth knowing.

The tiers, the mechanisms and the run: https://whittleos.com/guides/where-to-find-customer-problems

36 dead ideas carry 57 reasons, and the overshoot is the useful part

Boris Binyaminov — Fri, 18 Sep 2026 11:43:25 +0000

We publish one idea-sourcing run unedited, with every rejection and its reason attached. That is the only reason this post can exist: you cannot itemise deaths you did not record, and almost nobody records them.

The run: 69 candidates sourced from 41 sources, 24 of which were opened and read in full. 36 were dropped. 33 survived the checks. 5 reached the shortlist.

The most common cause of death is not a crowded market, a competitor, or the price being wrong. It is that there was no documented problem behind the idea at all — 21 of the 36, more than twice the next cause.

Now the part I would have got wrong reading the chart. Add the bars and you get 57 reasons against 36 dead ideas. The census looks like it partitions the drops and it does not: 21 of them failed more than one check.

Implementation note on that number, because it is the kind of thing that silently inflates. We count DISTINCT checks per dropped idea, not raw reason tokens — two spellings of the same check on one idea is one failure. Counting tokens would print a count of two against a row and then contradict it with the multi-failure line beside it. On this run both countings agree, so the fix was latent rather than a moved public number, which is exactly when it is cheap to make.

What the overshoot means in practice: a weak idea is rarely weak in one dimension. The thing with no evidence of a problem behind it is usually also the thing that is hard to sell, because both come from the same missing piece of work. If you are hoping that answering the one objection you have heard will save an idea, the arithmetic says it probably will not.

On the biggest row specifically: it is a judgement about the evidence, not about the market. The sweep looks for a documented complaint the idea would answer and did not find one. There are two honest readings — the problem is real but undocumented, or the problem was invented by the idea — and the check cannot tell them apart, which is exactly why it drops the candidate rather than pronouncing on the market.

The second reading is the one that costs months, because nothing about it feels wrong from the inside. An idea assembled from a plausible-sounding gap looks exactly like one assembled from a real gap, right up until launch.

Three limits, stated before anyone leans on the counts. These are our checks rather than the market's verdict. The ratings underneath are model output sampled fresh each run, so a second sweep would not reproduce this list. And it counts only what the sweep could see — a problem that lives in somebody's inbox is invisible to this method, which is a ceiling rather than a caveat.

The whole census, and the run it is counted from: https://whittleos.com/guides/why-startup-ideas-fail

The wrapper objection killed 6 ideas. Missing evidence killed 21.

Boris Binyaminov — Fri, 18 Sep 2026 11:42:18 +0000

Every AI idea meets the same objection: a vendor will ship this as a feature and there will be nothing left. It is a fair question. On the one idea-sourcing run we publish unedited, it is not the one doing the killing.

The run: 69 candidates in, 36 dropped, every drop carrying the checks it failed. The wrapper check was named on 6 of them. The check asking whether there was a documented problem behind the idea at all was named on 21.

That is 3.5 to one, and it is an argument about ORDER rather than about whether the wrapper question is soft. If you are holding an AI idea and worrying about a vendor roadmap, you are working on a question far down the list while the first one on it goes unexamined.

The stronger detail is in how those 6 drops were composed. Only 1 died of the wrapper question by itself. The other 5 each failed something else in the same pass.

What accompanied it on this run: hands-on support load, a missing documented problem, and a compliance barrier. Read that back and it stops sounding like an AI problem.

An idea that is a thin layer over a model is also, usually, an idea nobody documented a problem for, or one that needs a human in the loop for every customer, or one that cannot launch without a compliance review. The wrapper is the visible symptom because it is the part you can see from outside.

So the cheap checks go first, and here that is concrete. Is there a documented problem behind it — not a plausible one, one you can point at on a page somebody else wrote, with a link that opens. Can it run without you in the loop, because a model that needs supervision on every output is a support load wearing a product's clothes. Can it launch without a licence or an audit.

Each of those is settled by reading. The wrapper question, by contrast, is a forecast — and a forecast is the most expensive kind of question to answer first.

Where the AI question does bite: when the answer to what is left if they ship it is genuinely nothing. If the whole product is convenient access to a capability somebody else owns, the thing keeping you alive is their inattention, and pricing that as durable is how founders get surprised by a changelog. That is real. It is just not the common cause of death.

Limits: one run, one set of markets, one day. These are our checks, the ratings underneath are model output that samples fresh each run, and nothing here claims a rate.

The counted version, with the per-drop composition: https://whittleos.com/guides/ai-startup-ideas

Judge a SaaS idea on the parts you are worst at estimating, first

Boris Binyaminov — Fri, 18 Sep 2026 11:41:20 +0000

Open on the observation, because this audience has lived it: ask technical founders why the last SaaS idea failed and almost nobody says they could not build it. They say they built it and nobody came, or people came and would not pay, or people paid and then needed so much help that the business became a job.

The bias that produces that, stated as an estimation problem: the build is the only part you can estimate accurately, because you have done it before. Everything else is a guess wearing the clothes of an estimate. So reasoning pools where confidence is highest and the hand-waved parts are precisely the ones that decide the outcome.

The corrective is unglamorous: judge an idea on the parts you are worst at estimating, first.

Where they actually die, in four places. Distribution — not marketing as a category but a specific repeatable way to reach the buyer without an audience; if the honest answer is post about it and hope, there is no distribution and product quality does not substitute. This one kills more than the rest combined and is the one founders defer longest.

Pricing power — whether the problem is worth enough to the buyer to support a price that makes the business worth one person's time. A real problem worth a couple of dollars a month to its sufferer is a real problem you cannot build a solo business on.

Support load — what happens at scale, where scale for a solo founder means dozens of customers, not thousands. A product that needs a conversation per customer is a consultancy with a login screen.

Platform dependence — whether the business survives the platform it sits on changing its rules. Building on one API is building on somebody else's roadmap.

The ordering is worth more than the list, and this is the part to steal: answer cheapest-to-establish first. It takes an afternoon to establish that a problem is real and documented. It takes months to discover you cannot reach the buyer. Doing the afternoon first is most of the value, and it is free.

What is deliberately NOT in the filter: is this technically interesting. It matters to you, and a business you find boring is one you abandon — but it is not a survival constraint, and mixing preferences into a filter is how a filter stops filtering.

The evidence-order failure mode, which is the one an engineer will recognise as a bug: if you pick an idea and then research it, you will find support. Not through dishonesty — search rewards the query you typed, and you typed the one matching your idea. Read what a market complains about first and let candidates fall out of it.

Our own run works that way and the numbers are the point rather than the boast: 56 documented problems pulled from 41 sources across 20 sub-markets, with 24 pages read in full. Of those problems 32 carry a link you can open; the rest are labelled as our estimate.

That distinction is the whole discipline. A problem without a source is a hypothesis, and filing it as evidence is how a research process quietly becomes a confirmation process.

The four checks in the order that saves time: https://whittleos.com/guides/saas-ideas

Rank your ideas by time to an answer you cannot explain away, not by build hours

Boris Binyaminov — Fri, 18 Sep 2026 09:09:59 +0000

A low-cost startup idea is not one that is cheap to code. It is one you can DISPROVE before the code becomes expensive. Those are different ledgers, and technical founders default to the wrong one.

The default is build hours, which is the wrong measure at the stage where the largest risk is that nobody cares. A weekend utility can still be expensive if it absorbs six months of distribution attempts after launch. A product that would take months to build can be cheap to evaluate if a static mock and a payment request settle whether the buyer wants the outcome.

The cost that matters first is time to an answer you cannot explain away. That last clause is doing the work: an answer you can explain away is not an answer, and most early signals are exactly that.

So we ranked 8 real cards from our public idea library by first honest signal. 2 stop now, 3 can earn an answer in one week, and 3 get at most two.

The ordering does not reward the highest score, which is the part worth arguing with. A dead wedge belongs FIRST because it already produced the cheapest answer. A promising card that still needs payment intent belongs later, because waiting for that answer is rational and building before it is not.

The 3 levels of evidence, and none of them is a product build. Desk rejection at 0 days: the wedge fails before traffic is needed. Behavioural trust test at 7 days: a founder shares data or verifies a signup. Payment-intent test at 14 days: a buyer crosses checkout, prepays, or entrusts a live invoice.

Notice that the progression is not from easy code to hard code. It is from a desk-level disqualifier to a behaviour that costs the prospective buyer privacy, effort, or money. Those are the only two currencies that make a signal hard to explain away.

The stop-now group is the one people push back on. Those are not recommendations — they are ideas whose own cards already contain the answer. A weekly reminder plus export can be built quickly, and that is precisely why it is cheap for every incumbent to absorb and every user to reproduce. Sending it through a landing-page test would measure copy for a product whose differentiation has already failed.

The low-cost move there is to keep the kill. That is the whole discipline: the cheapest possible answer is the one you already have and are reluctant to accept.

One limitation we keep on purpose: all 8 cards come from a single Discovery market. Keeping one market means this is not a tour of every industry, and it lets the test shape rather than the market explain why ideas with similar buyers deserve different budgets.

The ranking, and the answer budget for each: https://whittleos.com/guides/low-cost-startup-ideas-for-developers