Validation is not a survey, a waitlist, or your friends being supportive. It is someone paying you for the outcome while the software is still hypothetical.
Sell the outcome manually, for money, before you write the software. Find twenty people who already have the problem, ask them what they did the last time it happened, then make a specific paid offer to solve it by hand. Interest is free and abundant; a payment is the only signal that survives contact with reality, and a week spent getting one is the cheapest research you will ever buy.
What counts as validation, and what does not
Almost everything founders call validation is a measure of politeness. Ranked from worthless to decisive:
Signal
What it costs them
What it proves
"Great idea, you should build it"
Nothing
They are a nice person
Survey response
A minute
The topic is comprehensible
Waitlist signup
An email address
Mild curiosity
Books a call with you
Real time
The problem is live for them
Introduces you to their boss
Their reputation
They believe it works
Pays you
Money
Validation
The line is at cost. A signal only carries information if giving it cost the person something they would rather have kept. Everything above the bold row is a reason to keep going, not a reason to start building.
The one-week method
Days 1–2. Find twenty named people with the problem. Not a segment, twenty humans you can contact. Communities where the problem is discussed, review sites where people complain about the current tool, your own former colleagues. If you cannot assemble twenty, the audience is unreachable and that is the finding.
Days 3–5. Ask about the last time it happened. What did you do, how long did it take, what did it cost, what did you try before, who else is affected. Never describe your idea first, because once you do every answer becomes a reaction to you rather than a description of their life.
Day 6. Make one specific offer with a price. "I will do this for you, by hand, this month, for $X." Specific scope, specific number, specific date. The vaguer the offer, the kinder the rejection and the less you learn.
Day 7. Count the commitments, not the compliments. Deposits, signed pilots, calendar slots, budget-holder introductions. Zero commitments from twenty conversations is a clear answer, and it cost you a week rather than a quarter.
The manual delivery is not a detour. It teaches you the workflow, the exceptions, the vocabulary and the objections, which is precisely the knowledge that makes the eventual software good. Productize only the steps that repeated across every paying customer.
Start from evidence, not from a brainstorm
The step before all of this is picking a problem that demonstrably exists. You do not have to guess at that. People document their problems constantly, in reviews, support threads, forum posts and one-star app ratings, and that record is searchable.
That is the thing we built BigIdeasDB to do: index over a million complaints, reviews and discussions so you can start from a problem someone has already written down in anger rather than from a whiteboard. The relevant starting points are the complaints database, Discover for patterns across sources, and idea validation for checking a specific one.
Evidence gets you a problem worth investigating. It does not get you a customer, and the two are routinely confused. The week above is still required.
Reading the signals honestly
Three traps, all of which feel like progress:
Pain without budget. The most seductive failure. A group with a genuine, painful, frequent problem and no money or no authority to spend it. Check who signs the cheque before you check whether the pain is real.
A market of one. Your own problem, solved for yourself, with no evidence anyone else structures their work the same way. Scratching your own itch is a fine start and a terrible stopping point.
Audience too broad to reach. "Small businesses" is not an audience, it is a census category. Specificity is what makes acquisition possible at all.
The version for the group sold 22 times more than the general one.
via r/SaaS
When to stop, and why it is hard
The hardest part of validation is not running it, it is acting on a negative result. Software has no natural stopping point: there is always another feature, another channel, another positioning tweak, and nothing ever forces the decision.
there was no natural point forcing me to stop, so I couldn’t tell whether I was giving the product enough time or simply funding something the market didn’t want
via r/SaaS
So set the stopping condition in advance, while you are still objective. Write down, before you start the week: "if I get zero commitments from twenty conversations, I will drop this and pick another problem." Then hold yourself to it. A written condition decided in advance is the only defence against a decision you will not want to make later.
Sell the outcome before you build the software. Find people who already have the problem, offer to solve it for them manually for money, and see whether anyone actually pays. A signup, a survey response or an encouraging conversation is interest; a payment is validation, and the gap between the two is where most products die.
How long should validating an idea take?
About a week of concentrated effort for a first signal. Two days finding twenty people who have the problem, three days talking to them about what they did the last time it happened, and two days making a concrete paid offer. If a week produces no one willing to commit anything, that is itself a result worth having.
Is a waitlist good validation?
Weak. A waitlist measures willingness to type an email address, which costs nothing and predicts very little. It becomes meaningful only when you ask the list for something that costs them something, such as a deposit, a scheduled call, or a pre-order. Convert a fraction of the list into any real commitment and you have learned something.
Does competition mean my idea is bad?
Usually the opposite. Competitors prove a budget exists and that someone has already done the expensive work of teaching the market that this problem is worth paying to solve. The useful question is whether a specific group remains badly served, uses an expensive workaround, or complains about the same limitation across every existing option.
What if people say they like my idea but do not buy?
Then you asked the wrong question. People answer hypotheticals kindly because the conversation costs them nothing. Ask instead about the last time the problem occurred, what they did, and what it cost them; then make a specific offer with a price attached and watch what happens to their enthusiasm.
Can I validate an idea without talking to anyone?
You can gather evidence without talking to anyone, by reading what people already write about the problem in reviews, forums and support threads. That tells you the problem is real and gives you the language for it. It does not tell you anyone will pay you specifically, which still requires making an offer to a named human.
Where these numbers come from
Revenue and growth figures were computed on 22 September 2026 from the TrustMRR corpus of 8,651 tracked startups: 3,787 reporting MRR above zero, 3,728 reporting active subscriptions, and 3,611 reporting a trailing 30-day growth figure. All are self-reported by founders who chose to publish revenue publicly. Products that never reached any revenue are largely absent from this corpus, which means the real distribution of outcomes is worse than the one shown here, not better.
Cite this page
Last verified: September 22, 2026
BigIdeasDB Research. (2026). How to validate a SaaS idea before you build it. BigIdeasDB. Retrieved from https://bigideasdb.com/guides/how-to-validate-a-saas-idea-before-building