How to Validate a SaaS Idea (Without Building It First)

Validation Is Not What Most Founders Think It Is

Most people use the word to mean encouragement. They describe the idea to ten people, eight say it sounds useful, and they call that validated. It is not. Those eight were being polite, they were not asked to give up anything, and none of them had the problem badly enough to have already tried to solve it. Real validation is the opposite activity: you are trying to kill the idea, cheaply, before it costs you a year. A test that cannot produce a no is not a test.

The Three Questions, In Order

Every validation exercise is three questions, and the order matters because each one is cheaper to answer than the next. First: is the problem real and frequent enough that someone is already spending money or time on it? Second: is there a specific group of people who have it badly enough to change what they currently do? Third: will that group pay you, specifically, rather than the incumbent or a spreadsheet? Founders almost always start at the third question because it is the fun one. Starting there is how you spend six months building for a problem nobody had.

• Is the problem real, frequent, and already costing someone something?
• Is there a narrow group who feel it badly enough to switch?
• Will that group pay you rather than the alternative they already use?

Start With the Problem, Not the Idea

Write the problem in one sentence with no product in it. If you cannot describe the pain without describing your solution, you do not yet understand the pain. "Small clinics lose two hours a week reconciling insurance claim rejections by hand" is a problem. "An AI claims assistant for clinics" is a solution wearing a problem costume. The first sentence can be checked against reality. The second can only be argued about.

Evidence That Counts, and Evidence That Does Not

The difference between a validated idea and a hopeful one is the class of evidence behind it. Some evidence is cheap to produce and means nothing; some is harder to find and settles the question. Sort your evidence before you sort your feelings about it.

• Counts: someone already paying for a worse solution, including spreadsheets and offshore VAs
• Counts: an existing tool with reviews complaining about the exact gap you would fill
• Counts: job postings hiring a human to do the thing manually
• Counts: a pre-payment, a signed letter of intent, or a deposit
• Does not count: survey responses saying they would probably use it
• Does not count: friends, your own enthusiasm, or a large TAM number
• Does not count: upvotes, likes, or a waitlist signup that cost nothing

Competition Is Evidence, Not a Reason to Stop

Founders treat competitors as a red flag. Usually they are the strongest signal you will find: someone else looked at this market, built a product, and is still charging for it. An empty market is more often a market that does not pay than a market nobody noticed. The question is not whether competitors exist — it is whether you can name the specific group they serve badly, and why that group cannot simply be served better by the incumbent adding one feature.

How to Read a Competitor Properly

Open their pricing page, their changelog, and their review pages, in that order. Pricing tells you who they think their customer is. The changelog tells you what they are investing in, which tells you what they will not let you own for long. Reviews — especially the three-star ones — tell you which customers they are failing and why. Three-star reviews are the most useful page on the internet for a founder: the reviewer liked the product enough to keep using it and is still annoyed enough to write.

• Pricing page: who they optimise for, and what the cheapest real plan costs
• Changelog: where their roadmap is heading, so you know what will be commoditised
• Three-star reviews: the gap between what they sell and what a segment needs
• Job postings: which functions they are scaling tells you where the money is

Demand Signals Worth Checking, and What Each One Means

Demand signals are proxies. None is proof on its own, and each fails in a specific way — so read them as a set, and know what each one cannot tell you.

• Search volume: real intent, but tells you nothing about willingness to pay
• Forum and community complaints: real pain, but often from people who will never buy
• Competitor headcount and funding: proof the market pays, but not that it has room
• Marketplace listings and their review counts: the closest free proxy for revenue
• Freelancer gigs for the same task: proof someone pays cash for the outcome today

Search Volume: Useful, and Routinely Misread

A keyword with ten thousand monthly searches looks like a market. It might be a market for information, not for software. Check the results page before you check the volume: if the top ten are blog posts and listicles, the searcher wants to read, not to buy. If the top ten are product pages with pricing, the searcher is shopping. That single observation is worth more than the volume number underneath it.

Talk to People — But Not About Your Idea

The Mom Test rule is simple: ask about their life, not about your idea. People lie about hypotheticals and are accurate about history. So do not ask "would you use a tool that does X". Ask what they did the last time the problem happened, how long it took, what they used, and what it cost them. If they cannot remember the last time it happened, the problem is not frequent. If they solved it with a spreadsheet and were fine, the pain is not expensive enough to sell against.

• Ask: when did this last happen, and what did you do?
• Ask: what did you try before that, and why did you stop?
• Ask: what does it cost you today, in money or hours?
• Never ask: would you use this, or would you pay for this

How Many Conversations Is Enough

Fewer than most people assume. Five to eight conversations with people who genuinely have the problem will tell you more than fifty survey responses. You are listening for repetition: the same workaround described by different people in the same words. When the third person independently describes the same spreadsheet, you have found something structural. When five people describe five different problems, you have found five people being polite.

Willingness to Pay Is a Separate Test

A confirmed, expensive, frequent problem still does not mean anyone will pay you for it. Budget lives with a specific person, and that person may not be the one suffering. Ask who signs off on a purchase like this, what the last tool they bought cost, and how long that purchase took. If the answer is that nobody has ever bought anything for this, you are not selling a product, you are creating a budget line — which is a much longer, more expensive sale than most first-time founders can survive.

The Cheapest Real Test: Ask for Something That Costs Them

Every strong validation test has the same shape: the person gives up something. Money is best, but time and reputation also count. A pre-order, a deposit, a signed pilot agreement, a scheduled hour of their week, an introduction to their boss — each of these costs the person something and therefore means something. An email address costs nothing and means nothing, which is why waitlists are the most over-read number in startups.

• Strongest: a pre-payment or deposit, even a small one
• Strong: a signed pilot or letter of intent with a start date
• Moderate: a booked call with the budget holder present
• Weak: an email signup, a like, a "definitely interested"

The Fake Door Test, Done Honestly

Put up a page describing the product as if it exists, price it, and drive traffic to it. Count how many people reach the payment step. It works because it measures behaviour under a realistic frame rather than opinion in a vacuum. Do it honestly: take nobody's money for something that does not exist, say plainly on the next screen that you are testing demand and when it will be ready, and give anyone who asked a real way to be told. A test that leaves people feeling tricked has bought you a number and cost you your first twenty customers.

The Concierge Test: Do It Manually First

Before writing software, deliver the outcome by hand for three to five customers. You do the reconciling, the formatting, the chasing — whatever the product would do — and charge for it. This is slower than building and it teaches more, because it surfaces the parts of the problem nobody mentions in interviews. Most failed products were technically fine and solved a slightly different problem than the one their customers actually had. A month of doing it manually finds that gap before the codebase does.

Market Size: Build It From the Bottom

Top-down sizing — "the global market is forty billion, we only need one percent" — is the single clearest signal that an idea has not been examined. Nobody gets one percent of a global market, and the number is almost always someone else's report about a category you are adjacent to. Build it from the bottom instead: how many businesses of this exact shape exist in the geography you can actually reach, what share could plausibly be reached in two years, and what would each pay per month. The resulting number is smaller, less impressive, and usable.

• Count the reachable segment, not the global category
• Use a price you have heard someone say out loud, not a hoped-for one
• State the assumptions separately so each can be checked and corrected

What Good Looks Like: A Worked Example

Suppose the idea is software that reconciles insurance claim rejections for small clinics. Bottom-up: roughly nine thousand clinics in the target region are large enough to have the problem and small enough to lack a billing team. A realistic two-year reach is two to three percent, so about two hundred clinics. Clinics already pay a part-time person roughly what a mid-tier SaaS seat costs, so a plan in that range is credible. That produces a business of a few hundred thousand a year at full reach — not a headline, but a real number built from three assumptions you can each go and check. Now every one of those three numbers is a thing to validate, in order.

Know What Would Make You Stop

Before you run a test, write down the result that would make you abandon the idea. Do it in advance, because afterwards every result becomes evidence of something. "If I cannot find three people who have paid money to solve this in the last year, I stop." That sentence is worth more than any dashboard. Founders rarely fail from a lack of data; they fail from having decided the answer before collecting it.

The Validation Sequence, Start to Finish

Run these in order. Each step is cheaper than the one after it, and each one can end the process — which is the point. Most ideas should die at step two or three, and dying there is a success, not a failure.

• 1. Write the problem in one sentence with no product in it
• 2. Find three people who have already paid to solve it somehow
• 3. Read the three-star reviews of whatever they paid for
• 4. Have five to eight history-based conversations, not pitches
• 5. Identify who holds the budget and what they last bought
• 6. Size it bottom-up from a reachable segment and a heard price
• 7. Run one test where someone gives up money, time or reputation
• 8. Deliver the outcome manually for three customers before writing code

The Mistakes That Repeat

The same handful of errors account for most wasted founder years. None of them are about intelligence; they are about the order of operations and about wanting a particular answer.

• Validating the solution instead of the problem
• Treating an absence of competitors as whitespace rather than as a warning
• Asking hypothetical questions and believing the answers
• Counting signals that cost the other person nothing
• Sizing top-down from a market report
• Choosing the test after seeing which one the idea would pass
• Building for three months to "see if people want it"

When Validation Says No

A no is the cheapest outcome available to you, and it is almost never a no to everything you learned. The conversations that killed the product usually contain the next one: a different segment with the same pain, a narrower version that one group would pay for immediately, or an adjacent job that came up repeatedly while you were asking about something else. Keep the notes. The second idea from a founder who has actually validated once is meaningfully better than the first idea from anyone.

Validate Your Idea in Minutes

You can run the first pass of this sequence with our free SaaS idea validator — it scores the idea across market, competition, differentiation, monetisation and execution, and tells you which of the three questions above is weakest so you know what to test first. It is a starting point, not a verdict: the score points you at the right question, and the conversations answer it.