Start with a claim that can be wrong
A broad idea such as “an AI tool for small businesses” cannot be validated. It has no precise buyer, painful job, alternative, price, or market. Turn it into a proposition narrow enough that weak demand would genuinely change your plan.
For [specific buyer], get [valuable outcome] without [costly or dreaded alternative] — at [price hypothesis].
For example: “For residential renovation contractors, identify margin leakage before invoicing without auditing every job by hand—at €149 per month.” This is a hypothetical proposition, not a validated opportunity.
Specificity does not prove demand. It makes demand measurable. The buyer becomes targetable, the promise can be understood, and the price creates a real trade-off.
A five-step SaaS idea validation protocol
Map the buyer and current workaround
Name the person who feels the problem, the person who controls the budget, how often the problem occurs, and what happens today. Those may be different people.
Run problem interviews before pitching
Ask for recent examples, costs, delays, failed workarounds, and existing spend. Do not ask “would you use this?” Interviews improve the hypothesis; they are not purchase evidence.
Publish one credible proposition
Use plain HTML to state the buyer, problem, outcome, operating model, price, and beta status. Give the page one primary action that represents the next real commitment.
Bring the intended market to the page
Recruit through a channel where that buyer can actually be reached. Record source, message, geography, and campaign so convenient traffic is not mistaken for market demand.
Apply thresholds you chose in advance
Compare qualified exposure, offer engagement, pricing behavior, and commitment with the minimum evidence required to keep investing. Do not lower the bar after seeing a weak result.
Demand First’s planned methodology follows the same logic: frame a falsifiable proposition, launch a controlled test, read behavior, and make a decision with the acquisition context attached.
Treat evidence as a ladder, not a pile
Signals are not interchangeable. A comment, an email, and a payment attempt impose different costs on the prospect. Read each one for what it can actually prove.
| Signal | What it can tell you | What it cannot prove |
|---|---|---|
| Search or community activity | The problem has observable attention | That your offer or price will convert |
| Problem interview | Pain language, workflow, buyer context | That the person will act or pay |
| Qualified landing visit | The proposition reached the intended segment | That the offer is wanted |
| Pricing interaction | The visitor examined the commercial trade-off | That budget will be approved |
| Detailed application | The prospect will spend time and reveal context | That they will purchase |
| Reservation or deposit | Intent survived meaningful friction | Retention, delivery, or product-market fit |
A waitlist can be useful, but only if it is treated as a low-cost signal. If you need stronger evidence, test a more expensive action transparently. The guide to pre-selling SaaS before building explains the difference between a waitlist, reservation, deposit, and genuine pre-order.
Set the build decision before traffic arrives
There is no universal conversion rate that validates every SaaS idea. A €19 self-serve product, a €10,000 enterprise workflow, and a regulated buying process create different funnels. Use thresholds tied to your channel, price, buying motion, and cost of the next build stage.
- Define the minimum number of qualified people who must see the offer before interpreting conversion.
- Define a BUILD threshold for the deepest observable action, not only page views or email captures.
- Define an ITERATE condition for a strong problem signal with weak offer or price response.
- Define a STOP condition and the budget or date at which you will honor it.
- Write down which result would justify the next irreversible cost: prototype, integration, hire, or full build.
Avoid the validation traps that create false confidence
- Friends, followers, and other founders are not a valid sample unless they match the buyer definition.
- Compliments and survey intent should not be reported as willingness to pay.
- A fake checkout hides the truth from the visitor. Disclose beta status before collecting payment information.
- Testing multiple personas, promises, and prices on one page makes the result hard to diagnose.
- Cheap broad traffic can increase visits while decreasing what you know.
- A successful acquisition test does not prove activation, retention, margins, or product-market fit.
If you are choosing among research techniques, use the SaaS validation methods comparison to match each method to the uncertainty it can reduce.