How to Validate a SaaS Idea Without Building It

You already know the advice is "talk to users." You have also noticed that nobody tells you what to actually say, who to say it to, or how to tell an encouraging answer from a real one. So you skip it, open your editor, and start on the part you know how to do.

That instinct is not laziness. Building is the only step with a visible finish line. Validation feels like stalling because it has no commit history. But the cost of skipping it is not the eight weeks of building — it is month eight, when the thing works, nobody is paying for it, and walking away feels like admitting the whole year was a waste. Sunk cost is what kills indie products, and validation is the only cheap defence against it.

Here is a two-week process with no code in it.

Here is the shape of the two weeks:

flowchart TD
    A["Write the claim"] --> B["Find 30 people with the problem"]
    B --> C["Ask about last time, never next time"]
    C --> D{"Have they already<br/>tried to solve it?"}
    D -->|No| E["Mild annoyance<br/>Stop here"]
    D -->|Yes| F["Ask for a costly commitment"]
    F --> G{"Did anyone pay<br/>or commit?"}
    G -->|No| E
    G -->|Yes| H["Deliver it manually once"]
    H --> I["Now build"]

Days 1–2: Write down the claim you are actually making

Most ideas are described as a product. Describe yours as a claim instead, because a claim can be wrong and a product cannot:

Someone with [specific role] currently handles [specific task] by [current method], and it costs them enough [time / money / risk] that they would pay [price] to stop.

Fill in every bracket. If you cannot name the current method, you do not have an idea yet — you have a feature. Every product competes with the spreadsheet, the group chat, the intern, or the sheer tolerance of doing it manually. Name your real competitor now, because your first ten prospects will tell you about it whether you asked or not.

Write the bracketed sentence somewhere you will see it daily. Everything below is an attempt to break it.

Days 3–5: Find thirty people who already have the problem

Not thirty people who would find it interesting. Thirty who are visibly dealing with it right now, in public, with a timestamp.

The ones that work:

• Complaint archaeology. Search the phrase a frustrated person would type, not the phrase a vendor would use. Nobody searches "workflow automation platform." They search "how do I stop manually copying this every Monday."
• Competitor reviews, filtered to three stars. Five-star reviews are marketing and one-star reviews are usually billing disputes. Three-star reviews are written by people who need the category and are unhappy with the options — the clearest description of an unmet need you will find anywhere, written by the person who has it.
• Job postings. A company hiring for a task is a company paying salary for it. That is a budget line with a name attached.
• The communities where the work is discussed. Not the founder communities — the practitioner ones. Browse circles by role and go where the job is done, not where products are launched.

Thirty is the number because it is small enough to finish in three days and large enough that one enthusiastic reply cannot convince you.

Days 6–10: Ask about last time, never about next time

This is the part that goes wrong, and it goes wrong in a predictable way. "Would you use a tool that..." is a question about an imagined future, and people are generous about futures that cost them nothing. You will hear yes, and you will build, and nobody will buy.

Ask about the past instead. The past already happened, so it cannot be flattered:

• When did you last run into this?
• Walk me through what you did.
• What did it cost you — hours, money, a missed deadline?
• What have you already tried? Why did you stop?
• Who else was involved when it went wrong?

That last one matters more than it looks. A problem with one person attached is a preference. A problem with three people and a deadline attached is a budget.

The tell you are listening for is whether they have already tried to solve it. Someone who built a spreadsheet, hired a contractor, or pays for a tool they dislike has told you the problem is worth money, with their behaviour rather than their opinion. Someone who has never tried anything has a mild annoyance, and mild annoyances do not survive a procurement conversation.

Do not pitch. The moment you describe your solution the conversation becomes about your feelings, and polite people protect those.

Days 11–12: Ask for something that costs them something

Not every signal is worth the same, and the gap is wider than it looks:

Interest is free, so interest tells you nothing. End the week by asking for a commitment with a price — not necessarily money, but something that costs real effort:

• A pre-order or a deposit.
• A paid pilot, even a small one.
• A scheduled hour with the person who controls the budget.
• A written description of their current process — which costs them twenty minutes and tells you they expect something in return.

A pre-order from one person beats a hundred people on a waiting list, and it is not close. One is a decision and the other is a bookmark.

If nobody will give you anything that costs them anything, you have your answer, and you have it in eleven days instead of eight months. That is not failure. That is the entire point of the exercise working correctly.

Days 13–14: Deliver the outcome manually, once

Before you write a line of code, deliver the result by hand for one person. Do the work in a spreadsheet, send it over as a PDF, do it on a call — however it has to happen. Charge for it if you can.

You will learn three things no amount of interviewing gives you:

1. How long it actually takes. Your pricing is a guess until you have done the work once.
2. Which step is the hard one. It is almost never the step you planned to build first. The product is usually the boring middle, not the impressive end.
3. Whether they use what you gave them. Someone who pays and then ignores the result has bought reassurance, not a solution. That gap is worth finding now.

This is the step most people skip, and it is the one that changes what gets built.

What two weeks actually buys you

Not certainty. Thirty conversations and one manual delivery will not tell you whether you have a business. What they do is make the next eight weeks of building a bet with evidence behind it rather than a bet with hope behind it.

And if the claim does not survive, you have spent two weeks instead of a year — with thirty new contacts in the exact market you were aiming at, which is a better starting position than the one you had on day one.

When you do build it, launch it where other founders are shipping. The people who will tell you the truth about version one are the ones who have already been through version one themselves.