How to Validate a SaaS Idea Before You Build the Nicest Version of a Problem Nobody Has

The first customer interview I wish I could get back is not one where someone hated the idea. It is one where they loved it.

They told me the product sounded useful. They asked intelligent questions. I left the call convinced I had learned something. What I had really learned was that people are kind when you ask them to imagine a tool you are excited about.

Months later, they did not buy it. That was not a betrayal and it was not a failed sales call. I had asked the wrong question. I was trying to validate my solution when I should have been trying to understand their existing problem.

That distinction is the whole job. Here is how to validate a SaaS idea without turning a few encouraging conversations into permission to build for three months.

What does it mean to validate a SaaS idea?

It means finding evidence that a specific group of people has a specific problem, experiences it often enough to care, and will trade something real to solve it.

The something real can be money, time, an introduction, access to their workflow, a pre-order, or a commitment to try a prototype on a date. It cannot only be a compliment.

The idea does not need to be secret or fully formed. In fact, a vague idea is easier to validate than a detailed product spec because it leaves room for the customer to describe the job in their own words. If you open with a feature list, people will politely react to the feature list. If you open with the situation, they will tell you whether the situation exists.

This is why a survey that asks “would you use this?” is almost always weaker than one conversation about the last time the person faced the problem. People are poor at predicting their future behavior. Their calendar, bank account, and current workaround are better evidence.

How do you validate a SaaS idea before building?

Start with a hypothesis written as a sentence:

People who do [specific job] struggle with [specific repeated problem] and currently solve it by [current workaround].

If you cannot fill in the workaround, you are too early to decide on software. The workaround tells you whether the problem is expensive enough to exist. Spreadsheets, copy-paste, paying someone, ignoring the task, and a stack of disconnected tools are all useful answers. “They have never thought about it” is useful too, just not in the way you wanted.

Then do these four things.

1. Find people who have already paid the problem tax

Do not recruit “startup founders” if your product is for founders who run weekly affiliate reporting across five networks. The broader label gives you lots of friendly people and almost no relevant evidence.

Find people who visibly do the job. Look at job titles, community discussions, product reviews, support threads, niche Slack groups, and posts where someone complains about the thing you think you can solve. The best first conversations are rarely with strangers who match a demographic. They are with people who recently described the pain in public.

You do not need thirty interviews before you are allowed to continue. Five conversations with people who really have the problem tell you more than fifty generic form responses. You are looking for repeated language, not statistical certainty.

2. Ask about the past, not your product

The questions that get useful answers are boring:

• Tell me about the last time you did this.
• What kicked it off?
• What did you try first?
• What happens if it goes wrong or takes too long?
• What have you paid for already?
• Who else is involved in the decision?

Notice what is missing: “Would you use an app that…” and “How much would you pay for…” Those questions invite people to help you feel better. The past-tense version forces a concrete story.

When someone says they have a workaround, ask to see it. A spreadsheet with twelve tabs is much better evidence than a confident answer. It shows what data matters, where the friction is, and which part they would never hand to a new tool.

3. Check whether the demand is visible without you

Search demand is useful evidence, not a verdict.

Read the search results for the problem. Are people looking for a solution, a template, an agency, or an explanation? Look at product reviews for the existing options. Read the one-star reviews especially. They are a free map of the compromise every current product makes.

Community discussion is another signal. A thread with ten people describing different versions of the same painful workaround is worth more than a keyword with a large number attached. Search volume tells you a phrase is typed. It does not tell you whether a buyer exists, whether the term is competitive, or whether the problem is a feature inside a larger product.

This is the part that keeps validation from becoming a taste test. You are checking whether the problem had a life before you arrived with a solution.

4. Ask for a commitment before you build the full product

Make the smallest offer that requires a decision.

That could be a paid design-partner slot, a calendar booking to set up a concierge version, a deposit that is refundable if you do not ship, or a landing page that asks for a work email and a specific use case. The commitment should have enough friction that a person who does not care will not complete it.

An email address alone is a weak signal. A person who shares their data, grants access to a workflow, or agrees to pay has crossed a different line. You still have not proved a business. You have proved enough to earn the next week of work.

What is the fastest way to validate a SaaS idea?

Sell the manual version.

If you think you can automate a weekly report, make the report by hand for one person. If you think you can organize intake from six channels, offer to organize it manually for three customers. If you think an AI agent can classify something, do the classification with a spreadsheet and a clear prompt behind the scenes.

This is not fake software. It is the shortest route to the thing you need to learn: what outcome someone actually values, what data is missing, and where the workflow breaks.

The manual version has another advantage. It tells you whether your proposed product is a tool or a service. Founders often want the answer to be tool because tools scale more cleanly. Customers may be paying for judgment, setup, accountability, or someone to own the ugly exception. Building the wrong form of value faster does not help.

How many people should validate a SaaS idea?

Enough that you stop learning the same thing every time.

There is no magic number. Five people who all use the same existing tool and complain about the same missing workflow is a strong signal. Twenty interviews where every person has a different problem is a signal too, just not for the product you planned.

Track the conversations in a simple table. Record the job, trigger, current workaround, cost of the problem, quote, and commitment. Do not record a vague confidence score. A table of actual behavior makes it much harder to remember every conversation as support for the idea.

The moment you hear a response that challenges your assumption, write it down in full. Those are the expensive facts. The compliments are cheap.

What counts as real validation?

Here is the hierarchy I use:

| Signal | What it tells you | What it does not tell you | | --- | --- | --- | | A person says it sounds useful | The idea is understandable | They will change behavior | | Someone joins a waitlist | Your promise got attention | They will return or pay | | A person agrees to a call | The problem may be relevant | The product is valuable | | Someone shows their workflow | The problem exists in reality | Your solution is right | | A customer pays or pre-orders | The outcome is valuable enough to spend on | The product will retain them | | A customer keeps using it | You may have a recurring product | You can acquire customers profitably |

The important thing is not to make a weak signal pretend to be a strong one. A hundred waitlist signups are exciting. They are still weaker than one person who pays after you have explained exactly what you will do.

What should you build after validation?

Only the part that turns the strongest signal into a repeatable outcome.

If three people agree to pay you to consolidate their reports, build the data import that makes that service faster. Do not also build team roles, webhooks, custom themes, and annual billing because every SaaS has those eventually. The first version should make the manual outcome less manual, not turn the whole imagined company into a dashboard.

This is where boilerplates are both helpful and dangerous. They can remove the chores of deploying, authenticating users, and collecting payment. They can also make a blank product feel closer to finished than it is. A SaaS boilerplate is useful right up until it becomes the work.

The same applies to Product Hunt. A launch can tell you whether a clear message gets attention, but it cannot validate a product before anyone has a reason to stay. I learned that the hard way across seven launches, and wrote down what Product Hunt actually measures.

Validation is not a ceremony you complete once

The comforting version of validation ends with a green light. You talk to ten people, write a conclusion, then begin “real” work.

The useful version keeps running. Every signup form, sales call, onboarding drop-off, refund, and support email is another chance to discover that the original model was incomplete. You do not graduate from customer evidence when the code starts. The code gives you a much better way to collect it.

Find people with the problem. Learn how they solve it today. Ask them for something that costs them a little. Build the smallest bridge between their old workaround and a better outcome.

If that feels less certain than spending a weekend making a polished landing page, it is. Certainty was never on offer. The point is to spend uncertainty where it teaches you something.