Last updated:
The cheapest time to discover that a SaaS idea is weak is before you build it. Validation does not mean asking friends whether the idea sounds useful. It means collecting increasingly costly evidence that a defined customer has a recurring problem, wants a specific outcome, and will change behaviour to get it.
Write the risky assumptions first
Before interviews, describe the idea in one sentence: “We help this buyer complete this recurring job with this measurable improvement.” Then list what must be true. There must be a recognisable buyer, a frequent or expensive problem, an unsatisfactory current method, a reachable channel, willingness to pay, and a product you can deliver responsibly.
Do not hide several markets inside one label. “Small businesses” is not a testable segment. “Independent dental groups with three to ten locations that reconcile supplier invoices manually” gives you somewhere to start.
Use an evidence ladder
- Observed problem: a prospect describes a recent event, its cost, and the current workaround.
- Access: they introduce the real user, show the workflow, or provide safe sample data.
- Time commitment: they attend a second session or test a prototype.
- Operational commitment: they agree to run a pilot with an owner, deadline, and success condition.
- Financial commitment: they pay, sign an appropriate order, or place a refundable deposit under clear terms.
Each step is stronger because it costs the prospect something. A wait-list signup is useful, but it is weaker than access to a real process. A compliment is weaker than a paid pilot.
Interview the past, not an imaginary future
Ask about the last time the problem occurred. What triggered it? Who noticed? What did they do? How long did it take? What failed? Who approved spending? Which systems and people were involved? Avoid leading questions such as “Would an AI dashboard help?” They invite politeness and speculation.
After several interviews, compare evidence. Repeated language, triggers, workarounds, consequences, and buyers are more useful than feature requests. If every prospect describes a different problem, the segment or promise may still be too broad.
Test the outcome before the software
You can often deliver the proposed result manually with a spreadsheet, a simple form, a scheduled report, or a service behind a basic interface. This is not the final product. It tests whether the output matters and exposes the exceptions your first design missed.
Protect customer data during this stage. Use the minimum data required, document access, agree how it will be used, and delete it when promised. “It is only a test” is not an excuse for weak security.
Use a prototype to test the workflow
A clickable prototype is useful for order, language, roles, and missing decisions. Give the user a realistic task and watch without teaching every click. Record where they hesitate and whether they can reach the promised outcome. Do not treat successful navigation as proof that they will pay.
Define the paid pilot
A useful pilot has one buyer, a narrow scope, a start and end date, the data and support required, a success measure, and a price or explicit commercial next step. State which parts are manual. Do not imply the product is complete when people are operating behind the scenes.
Examples of success measures include time to complete a reconciled report, percentage of eligible records processed correctly, reduction in avoidable handoffs, or adoption by the intended users. Choose an outcome the customer values, not a vanity count of logins.
Set decision rules before results arrive
Decide what will make you continue, narrow, change, or stop. You might require three relevant organisations to complete a pilot, two to convert to a paid plan, and no unresolved compliance obstacle. The numbers depend on your market, but writing them first reduces the temptation to reinterpret weak evidence.
What does not count as validation?
- a large market-size slide with no reachable buyer;
- social-media likes from people outside the segment;
- survey answers about hypothetical willingness to pay;
- a competitor’s success without evidence you can distribute differently;
- months of building followed by a launch described as a test.
When the evidence is strong enough, translate the validated outcome into a narrow SaaS MVP. If you are still looking for a direction, use the selection method in our SaaS ideas guide. Validation is not a ceremony that guarantees success. It is a disciplined way to make the next investment with less avoidable uncertainty.
Frequently asked questions
What is the best evidence that a SaaS idea is valid?
A relevant customer committing money, time, data, or access to a real workflow is stronger evidence than compliments, wait-list signups, or broad survey interest.
How many interviews should I run?
There is no universal number. Continue until the same costly problem, buyer, trigger, and current workaround repeat clearly enough to test a focused offer.