How to Validate a SaaS Idea Before You Build It

Most idea validation is theatre. You describe the product, people say it sounds useful, you build it, and nobody signs up. Nothing went wrong in the research — the research was measuring the wrong thing.

Opinions are free, so they carry no information. People are polite, they're agreeing with an idea rather than committing to a purchase, and they're predicting their own future behaviour, which humans are famously bad at.

Useful validation replaces opinions with costly signals — things people only do if they actually care.

The ladder of costly signals

Ranked by how much each one is worth, cheapest to most expensive for the person giving it:

1. Attention — clicking through, reading. Nearly free. Weak signal.
2. Time — a 30-minute call, a detailed answer. Real, but people are generous with founders.
3. Data — connecting an account, uploading a file, sharing something private. Strong: it implies trust and intent.
4. Money — a deposit, a pre-order, a card on file. Strongest available, by a wide margin.
5. Reputation — introducing you to their boss or their peers. They're spending credibility on you.

Anything at level 1 or 2 is weak evidence. Design your validation to reach 3 or 4.

Interview the problem, never the solution

The single highest-value change to how most founders do this.

Do not ask "would you use a tool that does X?" You'll get a yes, and it means nothing. Ask about the past instead, because the past is a fact rather than a forecast:

• "Walk me through the last time you did this."
• "What did that cost you — hours, money, mistakes?"
• "What are you using now, and what did you try before?"
• "Have you ever paid for something to fix this?"

That last one is close to a superpower. Someone who has already spent money on a problem is a buyer. Someone who says it's really annoying but has never spent a cent may not be.

Ten of these conversations will teach you more than a hundred survey responses, because you're collecting behaviour rather than opinion.

Four tests that produce real signal

The landing page with a real payment step. Describe the product properly, put a price on it, and add a checkout. Don't take the money — show "you're on the list, we'll be in touch" at the final step. The number of people who reach that screen is genuine purchase intent. A signup form measures curiosity; a payment step measures decision.

Concierge delivery. Provide the outcome manually before building anything. Spreadsheets, email, your own labour. It doesn't scale — that's the point. You'll learn what customers actually need in a week, and you can charge from day one.

The pre-sale. Offer a discounted first year to a handful of prospects, in exchange for a deposit and a promised delivery date. Uncomfortable to run, which is precisely why it's informative. If nobody pays, better to learn it now than after a build.

Competitor archaeology. Read the reviews of tools your buyers already use, filtered to the 2- and 3-star ones. That's a list of unmet needs from people who have already proven they'll pay for this category.

What "validated" actually looks like

Not applause. Something more like:

• You can describe the problem in the customer's own words, because you've heard the same phrasing repeatedly.
• You've found people who already spend money or meaningful time on the problem today.
• At least a few have committed something costly — a deposit, their data, a signed pilot.
• You can name who it isn't for, specifically.

That last one matters more than founders expect. An idea that suits everyone usually suits nobody enough to pay.

Hope for the disqualifying answer

The purpose of validation is to kill bad ideas cheaply, not to build confidence in the one you've already chosen. Signals worth taking seriously:

• People recognise the problem but have never sought a solution. It's a nuisance, not a budget line.
• Everyone wants a different first feature. You've found several problems, not one product.
• The interest exists but the buyer can't authorise spending. Correct problem, wrong person.

Finding any of these in week two saves you a build. That's a win, even though it doesn't feel like one.

When to stop validating and start building

Validation can become procrastination. Stop when you can honestly say: you know who it's for, you've heard the same problem described the same way by enough of them, and a few have paid or committed something real.

Then build the smallest version that delivers the core outcome — six to ten weeks for a focused MVP, and what that costs — and let usage answer the rest. Nothing you learn in interviews beats what you learn from people using the thing.

Validation isn't proving you're right. It's finding the cheapest possible way to discover you're wrong.

If you'd like a second opinion on whether an idea is ready to build — or scoped so the first version answers the real question — that's a conversation we have often. See how we approach SaaS development, or get in touch.