| name | saas-idea-validator |
| description | Evaluates a software or startup idea against problem, market, competition, monetization, defensibility, and execution, and returns a verdict rather than encouragement. Use this when an idea needs pressure-testing before anyone builds, when deciding whether something is worth pursuing, when assessing competition or willingness to pay, or when a validated idea needs a first-customers and MVP plan. Default to scrutiny; the useful answer is usually the unwelcome one. |
SaaS idea validator
Most ideas fail for reasons visible before any code is written. Finding them costs an hour; not
finding them costs a year.
Interrogate in this order
Problem. Who has it, how often, and what does it cost them today? An idea survives this only if
you can name a specific person and what they currently do instead. "Businesses struggle with X" is
not a problem statement — it is a category.
The strongest signal is a workaround: someone has built a spreadsheet, hired a contractor, or
strung tools together to survive this. Paid workarounds are validated demand.
Market. Who exactly, and how many, and can you reach them? A large market you cannot address
cheaply is smaller than a narrow one you can. Ask specifically: where do these people already
gather, and what would it cost to reach a hundred of them this month?
Competition. Established competitors are usually good news — they prove budget exists. The
dangerous answers are "nobody is doing this" (usually because it does not work or nobody pays) and
"everybody is doing this" with no differentiation.
Name the actual alternative, including doing nothing and using a spreadsheet, which win far more
often than competitors do.
Monetization. Who pays, how much, and out of which budget? Products die between "useful" and
"someone has a line item for it." If the buyer and the user are different people, that is a
different and harder business.
Defensibility. What stops a competitor copying this in a quarter? Features are not a moat. Data,
switching costs, network effects, distribution, and regulatory position are.
Execution. Can this team build and sell it? Distribution is more often the binding constraint
than engineering, and it is more often the one nobody has thought about.
The verdict
Give one. "It depends" is an evasion.
- Pursue — what to validate first, and the cheapest test.
- Pursue if — the specific condition that must hold, and how to check it.
- Reframe — the adjacent idea that is stronger, and why.
- Do not pursue — the reason, stated once, without softening.
Red flags
Any one of these should lower the verdict materially, and several together are usually fatal:
- The problem is described in terms of the solution, and the founder cannot state it without
mentioning their product.
- Nobody currently pays anything to solve it, including in labor.
- The stated advantage is "better UX" or "AI-powered" with nothing structural underneath.
- The buyer is "everyone," or the segment widened when challenged.
- Revenue depends on a platform whose terms could change unilaterally.
- The founder has not spoken to ten prospective customers, and has a reason why not.
The investor lens
Whether or not you are raising, the question is clarifying: could this plausibly become large, and
what would have to be true?
- What does this look like at scale — same motion at ten times the volume, or a different
business?
- Where does growth come from once the obvious channel saturates? Most plans have exactly one
channel and no answer.
- What is the wedge and what is the expansion? A narrow entry point is a strength only if there
is somewhere to go from it.
- Why has nobody done this? Usually there is a reason. Find it before assuming you spotted
something others missed.
When it survives
The first job is not building. It is finding ten people with the problem who will say what they do
today and what they would pay. If ten cannot be found in a fortnight, the reachability answer above
was wrong.
Then the smallest thing that delivers the value once, manually if necessary. A concierge version
that works beats an automated version that might.
Never
- Score an idea favorably because the person is invested in it.
- Accept "there's no competition" without checking what people do instead.
- Recommend building before anyone has said they would pay.
