How to Validate a SaaS Idea Before You Build Anything

A practical process for testing whether a SaaS idea is worth building, using conversations, a one page site, and a request for money before you write a prompt.

How to Validate a SaaS Idea Before You Build Anything
Listen to this post 7 min

AI tools made building cheap. They did not make building the wrong thing cheap. You still lose weeks, and you still lose the motivation that comes with seeing nobody use what you made.

I spent over twenty years in digital marketing analytics and conversion work before I started shipping my own products. The biggest lesson from that work carries straight over: what people say they want and what they actually do are two different data sets. Validation is the process of getting the second one before you invest.

Here is the process I use. It takes about two weeks if you push.

Step 1: Write the problem down in one sentence

Not the product. The problem. Use this format:

[Specific type of person] struggles with [specific task] because [specific reason], and today they handle it by [current workaround].

If you cannot fill in the current workaround, that is a warning. People with a real problem are already doing something about it, even if it is a messy spreadsheet or a sticky note. No workaround often means no pain.

Also be honest about the type of person. "Small businesses" is not specific. "Owners of one to three location dog grooming shops who book by phone" is specific. You can find those people. You cannot find "small businesses."

Step 2: Find ten people who have the problem

Ten is not a magic number. It is enough to see patterns and small enough that you will actually do it. Places I look:

  • People I already know in that industry, and people they know
  • Facebook groups, subreddits, and Slack or Discord communities for that role
  • Local businesses, if the idea serves them (walking in still works)
  • LinkedIn, searching by job title

Ask for 15 to 20 minutes to learn how they handle the task. Do not pitch. Pitching turns a research call into a sales call, and people get polite instead of honest.

Step 3: Ask about the past, not the future

The worst validation question is "Would you use an app that does X?" Almost everyone says yes. It costs them nothing to say yes.

Ask about what already happened instead:

  • "Tell me about the last time you had to do this."
  • "How long did it take?"
  • "What did you use?"
  • "What was the most annoying part?"
  • "Have you tried any tools for this? What happened?"
  • "Did you pay for anything to fix it?"

The last question matters most. If they have paid for a solution before, even one they quit, they have shown the problem is worth money to them.

Take notes during the call and write a short summary right after. You will forget the details faster than you think.

Step 4: Look for the pattern

After ten conversations, sort what you heard into three buckets:

  1. Strong signal: They described the problem without prompting, they have a workaround, and they have tried or paid for something.
  2. Weak signal: They agree it is annoying but have never tried to fix it.
  3. No signal: They do not really have this problem, or it happens rarely.

I set my bar before I start the calls so I cannot move it later. My personal rule of thumb is that if fewer than about a third land in the strong bucket, I either narrow the audience or drop the idea. Pick your own bar, but pick it in advance.

Step 5: Build a one page site, not an app

If the conversations look good, build a single landing page. This is a perfect first use of Lovable, by the way. You can have a clean page live in an afternoon.

The page needs:

  • A headline that states the problem in the words people used on your calls
  • Three or four lines on what the product does
  • One call to action: join a waitlist, request early access, or preorder
  • Analytics so you can see visits and signups (GA4 or similar)

One call to action, not three. Every extra choice makes the result harder to read.

Step 6: Send targeted traffic

Share the page back to the people you interviewed and the communities where you found them. Ask your interviewees if they know two others with the same problem.

You can also run a small paid ad test pointed at a narrow audience. Keep the budget small and fixed, and decide in advance what result counts as a pass. Check current ad platform pricing, since costs vary a lot by industry.

What you are measuring is the percentage of visitors who take the action. A visitor from a targeted community who signs up is a very different signal than a friend who signs up to be nice. Track where each signup came from.

Step 7: Ask for money

A waitlist email is a weak commitment. Money is a strong one. Before I build the full product, I try to get at least a few people to pay something:

  • A discounted founding member price, paid now, for access when it launches
  • A small paid pilot where I deliver the result manually
  • A deposit that is refundable if I do not ship by a set date

This feels uncomfortable the first time. Do it anyway. The people who say "I'd definitely pay for that" on a call and then decline to pay a small amount are giving you the most useful data in the whole process.

If nobody will pay anything, that does not always mean the idea is dead. It might mean the wrong audience, the wrong price, or the wrong framing. But it does mean you should not start building the full app yet.

Step 8: Deliver it by hand first, if you can

For a lot of ideas, you can deliver the outcome manually to your first few paying customers. A spreadsheet, a form, a weekly email you put together yourself. It is slow, and that is fine. It shows you exactly which parts are worth automating and which parts nobody cares about.

When the manual version gets too slow to keep up with, that is the right time to build.

What validation will not tell you

Validation lowers your risk. It does not remove it. You can do all of this right and still find that retention is weak once people actually use the product. That is normal. The goal is to make sure you are building something with a real chance, not to get a guarantee.

It also will not stop you from building if you really want to build. Sometimes I build things I know are weakly validated because I want to learn a tool or I need it myself. That is a fine reason. Just be honest with yourself about which one you are doing.

If you want feedback on your interview notes or landing page before you build, bring them to a 1:1 office hour and we will go through them together.

Was this post helpful?
R
Robert Dixon
Founder of NoCode Outlaws. Ships SaaS with Lovable, Supabase and Stripe, and teaches founders to do the same in live cohorts.
Build with us. Free account gets the starter course and the weekly build notes.
Start free
See the next cohort

Send Feedback

What would you like to share?