3
2 Comments

A low-cost idea is not one that is cheap to code. It is one you can disprove early.

A low-cost startup idea is not one that is cheap to code. It is one you can disprove before the code becomes expensive. I had those backwards for years.

Build hours is the wrong ledger at the stage where the biggest risk is that nobody cares. A weekend utility can be expensive if it absorbs six months of distribution attempts afterwards. Something 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 clause is the whole thing — most early signals are exactly the kind you can explain away, and you will.

So I ranked 8 real cards from our public idea library by first honest signal rather than by score. 2 stop now, 3 can earn an answer in a week, 3 get at most two.

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

3 levels of evidence, none of which is a product build. A desk rejection costs 0 days — the wedge fails before you need traffic. A behavioural trust test costs 7 — somebody shares data or verifies a signup. A payment-intent test costs 14 — somebody crosses checkout, prepays, or entrusts a live invoice.

The progression is not easy code to hard code. It is a desk-level disqualifier, then a behaviour that costs the buyer privacy, then one that costs them money. Privacy and money are the only two currencies that make a signal hard to argue with afterwards.

The stop-now group is where people push back, and it is the part I would defend hardest. Those are not recommendations — they are ideas whose own cards already contain the answer. A weekly reminder plus export is quick to build, which is exactly why it is cheap for every incumbent to absorb and every user to reproduce. Running it through a landing page would measure copy for a product whose differentiation has already failed.

The low-cost move is to keep the kill. The cheapest answer available is usually the one you already have and are reluctant to accept.

The ranking: https://whittleos.com/guides/low-cost-startup-ideas-for-developers

on September 18, 2026
  1. 1

    The falsifiability frame is useful, but I’d push back on privacy and money being the only currencies that count.

    Time, workflow change, access to real data, an introduction, or putting one’s reputation behind a pilot can all be costly commitments. A buyer who gives you two hours with their team and lets you into a live process may be showing more intent than someone who leaves a refundable deposit.

    I reckon the crucial step is writing the decision rule before running the test: which audience, what action, how much exposure, by when, and what result means stop. Otherwise a failed test is still easy to explain away as the wrong copy, channel or sample, and “cheap to disprove” quietly becomes another month of retesting.

    1. 1

      The currencies point is right and I stated it too narrowly. The reason money gets over-weighted is that it's the one least contaminated by how much the buyer likes you — but that's a difference of degree, not a clean line. Two hours with a founder who is good company is partly a measure of the founder. The strongest item on your list is access to a live process, precisely because it survives that test: an ops team does not hand over a running workflow out of politeness, and someone has to sign off internally.

      The decision rule written first is the half I'd defend hardest, and it's the one thing my own tool refuses to leave to the user. A validation plan has to carry its success criteria and its stop-loss up front, and it has to say in advance what a partial result means — that's the clause that stops the retelling. A failure gets argued with, but a partial gets quietly promoted to promising, and the only defence is having written down what partial would oblige you to do before you had one in hand.

      Worth disclosing against my own position: my product deliberately doesn't collect one of your currencies. It's built async-only — no calls, no demos — so the two-hours-with-their-team signal is one it never sees. That's a constraint chosen for a particular kind of founder, not a claim that it isn't evidence. On your terms it's evidence I've decided I can't afford to gather, which is a different sentence than the one I wrote.