A SaaS idea validation checklist that fails ideas early

The short answer: validate on behaviour, not opinion, and run the checks in cost order so the cheap ones get first chance to kill the idea. The three that matter most are existing spend on a worse alternative, three independent descriptions of the same problem, and a written kill criterion you committed to before looking. Everything else on this list is refinement.

The reason validation usually fails is not laziness. It is that the default search shape is confirmatory — you look for evidence the idea is good, evidence exists for almost any idea, and you find it. A checklist only helps if it is built to produce a no.

The nine checks, cheapest first

Checks one through five are answerable from public evidence in an afternoon. Six through eight usually need a few conversations, and the research you have already done decides what those calls should be about — the handoff in turning video research into a customer interview script. Nine costs nothing and is the one most often skipped, which is why it appears last on the list and first in practice — write it before you run check one.

Check 1: somebody is already paying for something worse

Existing spend is the strongest signal available and the fastest to look for. It resolves the question that sinks most first products — whether this is a problem people will pay to remove, or merely one they will complain about.

What counts: a paid tool people describe as inadequate, a contractor hired to do it manually, an internal hire whose job is largely this task, or a subscription people keep despite openly disliking it. That last one is the best of the four. A tool people pay for and complain about in the same breath is a market with a specific, funded, unhappy customer.

What does not count: enthusiasm for a free tool, or a large adjacent market. "The project-management space is worth billions" tells you nothing about whether anyone will pay you.

Check 2: three independent sources, not three mentions

The threshold is three unconnected people describing the problem in their own words, unprompted. The word doing the work is independent.

Ten people repeating a claim from one influential video is one source with an echo, and it is the most common way founders convince themselves. The test for independence is whether the descriptions use different vocabulary and different examples. When five sources describe the same problem in noticeably different words, they encountered it separately. When they use the same phrasing, they encountered each other.

Public discussion is a good source for this precisely because nobody was asked. A comment describing a workaround was written to help someone else, not to answer your survey, which removes the politeness bias that makes solicited feedback so unreliable. The longer form of that argument is in validating a SaaS idea without surveys, and the quantitative counterpart — reading demand off search and view data — is in validating a startup idea with YouTube search and view data.

Check 3: the workaround is the specification

A manual workaround is the highest-value artefact in validation. It proves the problem is worth effort, and it hands you the feature list.

People do not build spreadsheets for problems they do not have. When someone describes a fifteen-tab tracking sheet, a naming convention they enforce by hand, or a script they run every Monday, they have specified your product and demonstrated willingness to pay in the only currency that never lies — time already spent.

Checks 4 and 5: frequency and consequence

Frequency determines whether anyone remembers you exist. A genuine problem that recurs annually will not sustain a subscription, because eleven months of the year the product is invisible and the renewal looks like waste. Weekly or more is the comfortable zone.

Urgency is about consequence. Ask what happens if the problem goes unsolved for a month. If the answer is a named outcome — a missed deadline, an unbillable day, a customer lost — the budget exists. If the answer is that it stays irritating, you are selling a nice-to-have, which is a much harder business at any price.

Checks 6 and 7: can you reach them, and can they buy

Reachability means naming a specific place, not a demographic. "Solo consultants" is not a channel. "The three communities where solo consultants ask each other about proposal tooling" is.

This check has a pleasant property: if your evidence came from public discussion, you have already passed it. The places you researched are the places these people are, which collapses research and distribution into one activity — the structural advantage described in how indie hackers read demand signals.

The budget-owner check is duller and kills more ideas than any other on the list. A real problem, felt by someone with no authority to spend and no path to the person who has it, is a long enterprise sale wearing the costume of a small SaaS.

Check 8: why has nobody built it

If the idea is obvious and the market is real, something is stopping incumbents. Find out what before you assume it is inattention.

Good reasons — the ones you can exploit — are structural: it would cannibalise their pricing model, it serves a segment too small for their cost base, or it requires an integration their architecture makes awkward. Bad reasons, meaning ones that should worry you, are that it was tried and quietly removed, or that a regulatory or data-access constraint makes it unviable for everyone including you. Teardown method for finding out is in running a competitor teardown from public content.

Check 9: write the kill criterion first

Before any research, write one sentence: "I will abandon this if ____." Make it specific and observable — fewer than three independent sources, no evidence of existing spend, no reachable community.

This single habit does more than the other eight combined, because it converts an open-ended search for encouragement into a test with a failure condition. Research without a stated failure condition cannot fail, which is another way of saying it cannot tell you anything.

Running the list without it eating a month

The whole pass should take days. Checks one to five come from public material — creator content, comment threads, community posts — and the expensive part is not finding sources but comparing them, which is where most of the week disappears if you do it by hand.

The mechanical version: assemble ten to twenty sources on the problem area, extract each one with its claims attributed, then compare across them for repeated descriptions, workarounds, and consistent absences. The output you want is a count of independent sources per claim, because that count is what checks two and three actually measure. Running a couple of these passes a month sits inside Hobby at $19 with 2 projects and 25 videos; several ideas in parallel is what the 8 projects and 80 videos on Pro at $59 are for, and the tier comparison lays out the rest. The end-to-end version of one pass is in the seven-day playbook.

Closing thought

A good checklist is not a confidence-building exercise. It is a sequence of increasingly expensive attempts to prove yourself wrong, arranged so the cheap attempts go first. An idea that survives all nine is not guaranteed to work — but you will know exactly which assumption is carrying the weight, which is the difference between a bet and a hope.