How to validate a SaaS idea before you write any code

There is a story most founders know, either because they lived it or watched a friend live it. Someone has an idea on a Sunday. By Wednesday they have bought the domain. Three months of evenings later, the product is polished, the landing page is lovely, and launch day brings a handful of sign-ups from friends and then a long, confusing silence.

The product worked. The code was fine. Nobody needed it badly enough to change how they already did things.

This is not a rare outcome. In the CB Insights review of startup post-mortems that gets quoted everywhere, "no market need" was the most common reason companies failed, cited in roughly four out of ten. Not bad engineering. Building something the market did not want.

Validation is how you find that out before the three months, not after. Here is a method that takes about two weeks and very little money.

What validation actually means

Validation is not asking people whether they like your idea. People are kind. They will tell you it sounds great, and then they will not buy it.

Real validation is collecting evidence that people will change their behaviour for what you are building. Some evidence is much stronger than others, and it helps to think of it as a ladder:

Compliments ("Oh, that's a cool idea"). Worth almost nothing.
Opinions about the future ("I'd definitely use that"). Still very weak. People are bad at predicting what they will do.
Facts about the past ("Last month I spent two days doing this by hand"). Much better. This is real.
Giving you time (a follow-up call, testing a prototype, introducing you to a colleague). Getting serious.
Giving you money (a pre-order, a deposit, a paid pilot). The only rung that fully settles the question.

The method below climbs that ladder as fast and cheaply as possible.

Step 1: Write the problem down in one sentence

Before you talk to anyone, write a sentence in this shape: [A specific type of person] struggles with [a specific problem] when [a specific situation], and today they deal with it by [current workaround].

For example: "Freelance bookkeepers with ten to thirty clients lose hours every month chasing receipts by email, and today they handle it with a shared spreadsheet and reminder messages they send by hand."

That sentence forces you to choose a customer instead of "small businesses," and it names a situation you can ask about. The last part matters most, because your real competitor is almost never another startup. It is the spreadsheet, the email thread, or the habit of putting up with it. If you cannot name a workaround, notice that. A problem with no workaround is often one people do not feel strongly enough to solve.

Step 2: Look for people already complaining

Before you schedule a single call, spend an evening finding out what people say about this problem when nobody is asking them.

Read the bad reviews of existing tools. The one, two and three star reviews on software review sites and app stores spell out exactly what is missing, what is too expensive, and what made people leave. The same complaint showing up again and again is a gap.

Search communities in your customer's own words. Reddit, niche forums, Slack and Discord groups. Try phrases like "how do you handle," "is there a tool that," "[competitor] alternative," and "sick of." Note how people describe the problem, because that language becomes your landing page copy later.

Look for spreadsheets and hacks. When someone shares a template or a ten-step process they built to work around a problem, they are telling you it hurts enough to spend real effort on. That beats any complaint.

Map the competitors. Competition is usually good news, because it means people already pay to solve the problem. Browse directories by category to see what exists and what it costs. Our categories page and launch feed are a quick start for new tools. Owlytics.ai is built for market research for indie founders and small teams, and Product Trends Radar tracks launches and trends if you want to see what is gaining attention in a space.

If you find nothing at all, no competitors, no complaints, no workarounds, be careful. Occasionally that means something new. More often the problem is not painful enough to be a market.

Step 3: Talk to people the right way

Most founders do these conversations badly at first, because they pitch. You describe your idea, the other person reacts politely, and you leave with a compliment that feels like evidence.

Rob Fitzpatrick's book The Mom Test is the best short guide here, and its core rule is simple: talk about their life, not your idea. Ask about things that already happened.

Questions that work:

"Tell me about the last time this happened. What did you do?"
"How are you handling it today?"
"What have you already tried? Why didn't it stick?"
"How much time or money does this cost you in a normal month?"
"Have you paid for anything to fix it?"
"Who else on your team deals with this?"

Questions to avoid:

"Would you use a tool that did X?" (Everyone says yes.)
"How much would you pay for this?" (People guess low, or invent a number to be nice.)
"Do you think this is a good idea?" (You are asking for a compliment.)

Who to talk to. People who match your one-sentence description, and not your friends or other founders, who love ideas and make terrible test subjects. Find prospects in communities, on LinkedIn, or by asking each person whether they know someone else with the same problem. If your customer is a local business, a lead finder like Mantis Ai lets you describe the type of business you want and returns matching companies to contact.

How many. Aim for ten conversations. If ten people with the problem shrug about it, that is your answer. If six of them start describing their workaround in detail without being prompted, you are onto something. Write notes straight after each call, with their exact words. Memory is generous to ideas you already love.

Step 4: Run a smoke test with a landing page

Once the conversations suggest a real problem, test whether strangers care too. A smoke test is a simple landing page for a product that does not exist yet, sent to the right people, to see who takes the next step.

Keep the page small:

A headline in your customer's own words. Borrow the phrases from your interviews and from the complaints you found in step 2.
Three or four lines on what it does, written around outcomes, not features.
A visible price. This matters. A page without a price measures curiosity. A page with a price measures intent.
One call to action. "Get early access" or, better, "Reserve your spot."

You do not need a backend. A form service like FormSubmit emails you each submission without any server code, and a form builder such as Rowform works well for a short follow-up survey after someone signs up. If writing the headline feels hard, it can help to study how other products frame their pitch. HookBert is a database of product hooks with click data, which is a decent way to see what kind of opening line gets attention.

Then send real, targeted traffic to it: the communities where your interviewees spend time (following each one's rules), the people you already spoke to, or a small, narrowly targeted ad. A few hundred visitors from the right audience tell you more than thousands from a launch spike.

You will see all sorts of target conversion rates quoted. Treat them as rough guides. If visitors who match your description sign up at a healthy double-digit rate, that is encouraging. If almost nobody does, the problem, the audience or the message is off, and your interview notes should tell you which.

Step 5: Ask for money before you build

This is the step most people skip, because it is uncomfortable. It is also the step that tells you the most.

Asking for money does not mean taking advantage of anyone. It means offering people a fair deal for believing early. A few ways to do it:

Founding-member pricing. A lower price locked in for life, paid now, for the first twenty or fifty customers.
A refundable deposit. A small amount to hold a spot, refunded in full if you do not ship or if they change their mind.
A paid pilot. For business software, offer a small group a few months of hands-on service at a reduced rate while you build.
Pre-orders with a date. "Delivered by the end of next quarter, full refund if not."

Be completely honest that the product is not built yet, and make refunds easy. Then watch what happens. "Sounds great, let me know when it's ready" is a polite no. "How do I pay?" is the sound of a real problem. Even three or four paying customers before you write code change your motivation, your priorities, and your confidence that you are not building in a vacuum.

Testing a new feature on an existing product works the same way in a lighter form: add the button before the feature exists, tell people who click that it is coming, and count the clicks.

Step 6: Deliver it by hand first

Before you automate anything, try doing the job manually for your first few customers. This is sometimes called a concierge test.

If your idea is a tool that turns messy sales data into a weekly report, make the report yourself in a spreadsheet for five customers. If it is a scheduling tool, do the scheduling by email. It will not scale, and it is not supposed to.

Doing it by hand shows you which parts customers actually use, where the edge cases are, and whether people still care in week four, which predicts a real business far better than week-one excitement. When you finally build, you are building something you have already run.

Reading the results honestly

The hardest part of validation is not the work. It is accepting what the work tells you.

Decide your criteria before you start. Something like: "If at least six of ten interviewees describe a painful workaround, and at least three people pay a deposit, I build it. If not, I change the audience or drop the idea." Writing this down beforehand stops you from moving the goalposts once you are attached.

Signals that feel good but mean little:

Friends and family saying they love it
A spike of waitlist sign-ups from one viral post
Upvotes and likes
"I'd definitely use that"

Signals that actually mean something:

People describe the problem before you mention it
They ask when it will be ready, and follow up without being chased
They introduce you to a colleague with the same problem
They pay, even a small amount
They offer you their real data to test with

Weak results are not a failure. You just saved yourself months, and the conversations often point to a neighbouring problem people care about far more.

A two-week validation plan

If you like having it laid out, here is one way to fit everything into two weeks of evenings and a weekend:

Days 1 and 2: Write your one-sentence problem. Read bad reviews and community threads. Collect phrases and workarounds.
Days 3 and 4: Map the competitors and their prices. Make a list of thirty people who match your description.
Days 5 to 9: Hold eight to ten interviews. Write notes immediately after each one.
Day 10: Review the notes against the criteria you set. Rewrite your problem sentence if needed.
Days 11 and 12: Build a one-page smoke test with a price and a single call to action.
Days 13 and 14: Send targeted traffic. Offer founding-member pricing or a deposit to the most interested people.

At the end you will have notes, numbers and, with luck, a few people who have already paid. That beats a gut feeling.

Mistakes worth avoiding

Spending three weeks on the landing page. It is a test, not a launch.
Validating with the wrong people. Two conversations with people who have the problem beat ten with people who do not.
Asking leading questions. If you hear yourself describing your solution, go back to asking about their week.
Choosing a market you cannot reach. If you cannot find a hundred ideal customers, even a validated problem will be hard to sell to.

Frequently asked questions

How many customer interviews do I need?

Ten is a good starting number for most B2B SaaS ideas. You will often see clear patterns by the fifth to eighth conversation. If the signals are mixed after ten, narrow your audience and do another five rather than talking to fifty people at random.

Is a waitlist enough to validate an idea?

On its own, rarely. Joining a waitlist costs nothing, so it mostly measures curiosity. A waitlist becomes meaningful when it is paired with a visible price, follow-up conversations, or a deposit.

Can AI tools validate my SaaS idea for me?

They can help with the groundwork. An assistant is good at summarising review themes, suggesting interview questions, and pointing out competitors you missed. What it cannot do is tell you whether a real person will pay. Simulated customers are not customers, and their enthusiasm costs them nothing.

When should I stop validating and start building?

When you have real people with a painful, recurring problem, a clear sense of how they handle it today, and at least a few who have committed time or money. You will never be completely certain. You are aiming for enough evidence to justify the next three months, not proof.

Once you have built it and you are ready for strangers to see it, submit your tool to FeaturedLane. A person reviews every listing, and new launches appear on the launches board and the leaderboard, where early users go looking for new tools.