How to Validate a SaaS Idea Before Building

Complete this sentence:

I am deciding whether to build [a specific solution] for [a specific role] who needs to [complete a specific job]. Before investing more, I need to understand [the biggest uncertainty].

"People need better productivity tools" is too broad to investigate usefully. "Independent recruiters lose track of candidate follow-ups across several clients" is a narrower starting hypothesis. It is still a hypothesis until you find relevant evidence.

Mark each check as supported by a source, still an assumption, or challenged by evidence. These labels describe your notes; they are not a statistical measure of demand.

Use material you already have permission to use, such as existing customer feedback or relevant public discussions. For each item, record:

• The original URL or a private source reference.
• When it was published or collected.
• The relevant statement and its context.
• Whether it describes something that happened or something that might happen.
• Whether it supports or challenges your hypothesis.

Two reposts of one complaint are one underlying observation. A popular post may help you find a question, but popularity alone does not show willingness to pay. If you cannot establish who the statement applies to, keep that uncertainty in the note.

Use this complete worksheet as a starting point. It is available without sign-up and can be selected and copied directly.

Idea:
Target customer and situation:
Decision I need to make:
Problem hypothesis:
Current alternative:

Supporting evidence:
- Source reference / date:
- What actually happened:
- Why it matters:

Conflicting evidence:
- Source reference / date:
- What challenges the idea:

What is still unknown:
One next test:
The action I will observe:
How the intended audience will reach the test:
What result would make me continue, change direction, or stop:
Observed result: not tested yet

Choose an action that fits your current stage. For an early idea, starting validation can reveal whether someone will share a concrete problem and continue a conversation. It does not establish willingness to pay for a finished SaaS product.

For a page experiment, write down the offer and decision rule before looking at results. Separate visits, applications, qualified applications, use of the result, and payment.

If the page receives no relevant visitors, record that the acquisition test has not supplied a useful sample. A page without visitors cannot tell you whether its offer converts.

Ready to test a specific promise? The fake door testing guide helps you define an honest experiment, its audience, and how to interpret the responses.

Start with materials you already have permission to use and a clear record of what is missing. You can investigate the problem before your own site has traffic. That research does not replace observing whether people use or pay for your offer.

1. 1Write one problem hypothesis and collect relevant source material.
2. 2Turn it into one specific offer and a useful page that answers the visitor's question.
3. 3Check whether the intended audience actually reaches that page.
4. 4If visitors arrive, distinguish applications, qualified requests, use of the result, and payment.

Publishing the page gives you somewhere to receive interest. It does not supply an audience by itself. When relying on organic search, keep the acquisition question open until you have relevant visits. Choose a review date for your own effort, and record "insufficient acquisition evidence" if too few people arrive.

You do not need to call an idea validated in order to learn which uncertainty to investigate next.