How to validate a SaaS idea before you build it

Most SaaS ideas fail for the same reason. Not because they were built badly, but because they were built at all, before anyone checked whether people actually wanted them. Building is the expensive part. Finding out is cheap, if you do it first.

This is how to test an idea before you commit real money to it, and how we think about it when we build our own products and our partners’ products alike.

What does it mean to validate an idea?

Validating an idea is not asking people whether they like it. It is proving two things: that a real group of people has the problem you think they have, and that they will do something costly to solve it. Costly does not have to mean money at first. It can mean handing over an email, joining a waitlist, or giving up time. The point is that they act, rather than nod along.

If you cannot find people with the problem, the product does not matter. If you can find them but none of them will lift a finger to fix it, the problem is not painful enough to build a business on. Both are worth knowing before you write a line of code.

Why bother validating before you build?

Because building is where the money goes. As we wrote in what it costs to build an app, most of the cost of a product is decided in what you choose to build. Validation is how you avoid spending that money on features, and sometimes whole products, that nobody turns out to want.

The cruel part of skipping it is that you often cannot tell the difference until the end. A product built on an unproven idea looks exactly like a product built on a proven one, right up until you launch it and the silence tells you which one you had. Validation moves that moment forward to when it is still cheap to change your mind.

Who should you talk to, and what should you ask?

Talk to people who have the problem now, not friends and not investors. Ten real conversations with people in your target group are worth more than a hundred survey responses.

Ask about their past, not your idea. “Tell me about the last time you dealt with this” beats “would you use an app that does this.” The first gets you the truth about what they actually do and what it costs them. The second gets you a polite guess about a future that has not happened. You are listening for a problem people already spend time, money, or frustration on, because that is a problem they will pay to remove.

How do you test demand without building anything?

Once you believe the problem is real, test whether people want your solution before you build it. A few cheap ways, roughly in order of effort:

• A landing page. Describe the product as if it exists, with one clear action: join the waitlist, request access, or pre-order. Send real traffic to it with a small ad budget and see how many people take the action.

• A waitlist or pre-sale. An email is a small price, and money is a larger one. People who pay before the product exists are the strongest signal you can get this early.

• Doing it by hand. For many ideas you can deliver the outcome manually for your first few users, with spreadsheets and effort, before any software exists. If people value the result when it is held together with tape, they will value it more when it is a real product. If they do not, you just saved yourself the build.

None of these need the product. All of them tell you something the product would have told you later, at a fraction of the cost.

What actually counts as a signal?

The signals that matter all cost the other person something. Someone joining a waitlist, pre-paying, replying to book a call, or coming back a second time without being chased. Those are people voting with something real.

The signals that do not matter are the comfortable ones: likes, “great idea,” “I would definitely use that.” They feel like progress and they are the most common way founders talk themselves into building the wrong thing. When you catch yourself collecting compliments, go back and ask for a commitment instead.

When are you ready to build?

You are ready when you have a group of people with a real problem and clear evidence that they will act to solve it. Not certainty, that never comes, but enough signal that you are building to serve demand you have seen rather than demand you are hoping for.

Then you build the smallest version that delivers the one thing those people came for, put it in front of them, and let what they do next guide the rest. This is exactly how we work: we validate lean, then build lean. Because we reuse proven patterns across every product, a validated idea can become a real first version fast, without the timeline or the bill of starting from scratch.

Validation does not stop at launch either. Finding the next hundred customers is the same discipline, which is why our partnerships cover marketing and sales as well as the build. If you have an idea and want a straight opinion on how to test it before you spend on building it, get in touch. The cheapest conversation in the whole project is the one you have before anything is built.