How to Validate a SaaS Idea Before You Build (2026)

Start With a Problem and a Person

Validating an idea doesn't prove it will succeed. It means collecting evidence that a specific group has a problem, cares enough to act on it, and would pay for a better way, so you can decide whether months of building are worth it.

Start by writing the idea down as a problem, not a product. Most ideas arrive as a solution ("an AI dashboard for agencies"), and a solution is hard to test: people can't tell you whether they'd want something they've never seen. A problem is easy to ask about. Use one sentence with four parts:

[Who] struggles to [do what] because [why], and today they [current workaround].

For example: "Freelance bookkeepers struggle to collect client receipts each month because they arrive by email, chat and paper, and today they chase each one by hand from a spreadsheet." Then check the sentence:

• The "who" is narrow enough to find. "Small businesses" isn't a group you can search for. "Dental clinics with two to five chairs" is.
• The problem is something they do, not something they feel. Collecting receipts can be observed. Feeling disorganized can't.
• There's a current workaround. If people do nothing about the problem today, it may not hurt enough to pay for.
• You can name where these people gather: forums, subreddits, Slack groups, events, job titles.

Before you talk to anyone, write down what would change your mind, such as "If most people I interview haven't tried to fix this in the last six months, I'll rethink it." Setting the bar in advance stops you from reading every conversation as a yes.

Find People Who Already Talk About It

If a problem is real, people complain about it somewhere without being asked. That's your cheapest evidence, and where you'll find people to interview.

• Communities: subreddits, forums, and Slack or Discord groups for the profession. Search for the task, not your idea: "how do you collect receipts from clients", not "receipt automation app".
• Reviews of existing tools: the two- and three-star reviews on G2, Capterra, the Chrome Web Store or the App Store list what people wish someone would fix. Note which complaints repeat.
• Questions and job posts: people asking "is there a tool that…", and companies hiring someone to do the task by hand.
• Search: the keyword matrix generator suggests phrases people type when they have the problem. Google's Keyword Planner estimates their monthly searches but needs a Google Ads account with billing set up. Google Trends shows relative interest on a 0 to 100 scale, not search counts, and shows low-volume terms as zero.

Keep a document of each quote, where it came from and a link. After a few evenings, the same complaints should come back in similar words. Save them for your headline and landing page.

A quiet result is a result too. If nobody describes the problem, it's rare, people word it differently, or it isn't painful enough to talk about. Try other words before you give up, but take the silence seriously.

Problem Interviews: What to Ask

Complaints show that the problem exists. Conversations show how much it matters. Interview people who have the problem now, starting with those whose posts you saved and anyone you know who does the job. Message them one at a time:

The early adopter outreach generator drafts versions for X, LinkedIn and email, and our guide to cold email for SaaS founders covers emailing strangers without hurting your domain.

What to ask

Ask about what people have done, not what they would do. Past behavior is evidence; predictions are guesses. Questions to adapt:

What not to ask

• "Would you use this?" Most people say yes to be kind. It costs them nothing.
• "How much would you pay?" People are poor at predicting this. Ask what they pay now instead.
• Your pitch. Once you describe your solution, the call turns into feedback on your idea, and people get polite.
• Leading questions, such as "Don't you hate how slow it is?" You'll get the answer you planted.

Compliments ("great idea", "I'd totally use that") feel like progress and tell you almost nothing. Evidence is a specific story about the problem, money or time already spent on it, a workaround they built themselves, or an offer to give you something: an introduction, another call, a payment. Rob Fitzpatrick's book The Mom Test covers this way of interviewing in depth.

After each call, note their words for the problem, what they use today and what it costs them. Plan for ten or so conversations with one group, and stop when they stop surprising you. If every conversation sounds different, your "who" is too broad.

Look at What People Already Pay For

A strong sign that a problem is worth solving is that people already spend money or time on it. Don't look for an empty market: it often means nobody pays.

• Competitors: list the tools that solve the problem, or part of it, and their prices. Paid competitors with customers prove people buy. Your job is to find who they serve badly.
• Workarounds: spreadsheets, automation chains, a virtual assistant, a freelancer, an agency. Each one has a cost you can put a number on.
• Time: hours a month spent on the task, multiplied by what that person's time is worth. That's the budget a manual process quietly uses.
• Who holds the budget: can the person with the problem buy a tool, or does a manager have to approve it?

Then compare. If the problem costs a business real money each month and the best alternative is clumsy, there's room for a product at a fair price. If it costs someone a few minutes a week, people may agree it's annoying and still never pay. Our micro-SaaS pricing playbook shows how to turn what you learn here into a first price.

Test the Offer: Waitlists and Pre-Sales

Interviews test the problem. A landing page tests whether your description of the solution makes strangers act. Keep it short:

1. A headline in your users' words, naming the problem and who it's for. The value proposition generator drafts versions to compare.
2. Three or four lines on how it will work, with a sketch or mockup if you have one. Say plainly that it isn't built yet.
3. A price or price range, if you can. A signup next to a visible price says more than one without.
4. One action: join the waitlist, book a call or reserve a spot.

Send people who match your "who": your interviewees, the communities where you found the complaints (within their rules) and direct messages. Tag each link so you know where signups came from; our guide to tracking launch traffic shows how. For the page itself, see landing page copy for developers.

What the numbers can and can't tell you

• They can show which message lands, if one headline or audience brings clearly more signups, and which channel has the right people.
• They can't tell you whether people will pay. An email address costs nothing to give.
• They mean little at small numbers. With a few dozen visitors, two signups versus four is noise.
• They mislead with the wrong traffic. Visitors without the problem make any page look bad; friends make any page look good.

Email every person who signs up and ask what made them do it. The replies are worth more than the count.

Pre-sales

The clearest test is someone paying before the product exists. A payment answers the question every other test leaves open. Some ways to do it:

• A founding-customer offer: a discounted first year, paid now, for a product delivered by a stated date.
• A paid pilot: for business buyers, a fee to set the product up for their team, credited against their first months.
• A refundable deposit: a small amount to reserve a spot, returned on request.

You don't need a billing system. Stripe's Payment Links, for example, give you a hosted checkout page without writing code, can limit how many purchases a link accepts, and can be refunded from the dashboard.

Be honest about what people are buying: say clearly that the product isn't built yet, when you expect to deliver, and that they'll get a full refund if you don't. Then keep that promise. Ask your interviewees first; for them it's a natural follow-up, not a cold sale. If someone who described the problem in detail won't put down even a small amount, ask why. "Not now", "my boss decides" and "it would need to do X" are all useful answers.

Common Validation Mistakes

• Asking friends and family. They want to support you, which makes their answers unreliable.
• Pitching instead of listening. If you spent most of the call explaining your idea, you learned little about their problem.
• Talking to everyone. Freelancers, agencies and large companies in one round give you contradictory answers. Pick one group per round.
• Treating a waitlist as demand. Signups are interest. Payments are demand.
• Hearing only the yeses. People who say "not for me" often show you who the product is really for.
• Validating forever. Research can become a way to avoid building. Give it a deadline, such as three or four weeks, and decide.
• Building first and validating after. Changing a sentence on a landing page is far cheaper than changing a product.

Build, Change or Drop It

When your deadline arrives, compare what you found with the bar you set at the start. Most ideas land in one of three places:

Dropping an idea after a few weeks isn't a failure. You've spent weeks, not a year, and the conversations often point to a better problem.

If you build, keep the people from your interviews close. They're your first testers; our guide to finding beta testers covers that stage, and getting your first 100 users covers what comes after. Once the first version works for the people who paid, launch it on Hauntboard.