Validate Before You Build: A Solo Founder's Playbook
Five cheap experiments that tell you whether an idea has legs, before you write a line of code.
Most failed startups did not fail at building. They built the thing competently and then discovered no one wanted it. Validation is the work you do so that the thing you spend six months building is a thing someone is already trying to buy. For a solo founder with limited time and no team to absorb a wrong turn, it is the highest-leverage work there is.
The mistake is treating validation as a survey. You describe your idea, people say it sounds useful, you feel great, and you start building. But “sounds useful” costs the other person nothing to say. The only signals worth trusting are the ones that cost someone something.
What validation actually measures
You are trying to answer one question before you commit: when saying no is easy and saying yes is a little bit expensive, what do people do?
Everything below is a way of making “yes” cost something small — attention, time, a booked slot, a few dollars — so that the yeses you get are real. A validated idea is not one people admire. It is one people pull toward before it exists.
Enthusiasm is free. Behavior is expensive. Only measure the expensive thing.
Run the cheapest killing experiment first
Order your experiments by how fast and cheaply they could prove you wrong. Your goal is not to confirm the idea — it is to try to kill it before you have sunk months into it. If it survives the cheap tests, then you build.
Here are five, roughly from cheapest to most committing.
1. The ten-conversation test
Find ten people who have the problem and talk to them — not about your idea, about their life. Ask what they do today, what they have tried, what they spend to work around it, and when they last felt the pain. You are listening for a problem people already spend time or money on. If they have never tried to solve it, it is not painful enough to build a business on.
The tell: they get animated and specific, and they describe workarounds they have already cobbled together. Vague agreement is a no.
2. The landing page test
Write the promise as if the product exists. One clear headline, the problem, the outcome, and a single call to action. Drive a small amount of traffic — a relevant community, a few targeted posts, a tiny ad budget — and measure whether strangers who did not know you will give you their email in exchange for the promise.
The tell: strangers convert. Friends signing up out of kindness do not count; you want people who have no reason to be nice to you.
3. The waitlist-with-intent test
A plain email field is weak. Add a question that reveals intent: “What are you using now?” or “What would you pay?” People who write a thoughtful answer are telling you the problem is real for them. People who leave it blank were being polite.
4. The concierge test
Deliver the outcome manually, by hand, for a few people — no product, just you doing the work behind a curtain. If you can create the value with a spreadsheet and effort and people are glad you did, the value is real and the software is just a way to scale it. If doing it by hand for free still does not excite anyone, no amount of code will fix that.
5. The pre-sale test
The strongest signal short of a launched product: ask for money before you build. A founding-member price, a deposit, a paid pilot. This terrifies people because a “yes” here is unambiguous and a “no” removes your excuse to build anyway. That is exactly why it is the best test.
Reading the results honestly
The hard part is not running the tests. It is being honest about what they tell you, especially when you have already fallen for the idea.
- Pull beats push. If you are dragging people toward a “yes,” that is push. If people are asking when they can have it, that is pull. Only pull validates.
- Costly beats free. Rank your evidence by what it cost the other person. A booked call outranks a like. A pre-payment outranks a waitlist.
- Specific beats general. “I’d pay $40 a month to stop doing X every Friday” is signal. “I’d definitely use this” is noise.
When to stop validating and start building
Validation can become its own kind of procrastination. You do not need certainty; you need enough costly yeses that building is the reasonable next step. A practical bar: ten people described the same pain in similar words, strangers converted on the promise, and at least a couple committed something real — a deposit, a pilot, a booked start date.
Hit that, and you have earned the right to build. Miss it, and you have saved yourself the most expensive way to learn the same lesson. Either way, the week you spent testing beats the six months you would have spent building the wrong thing.
Frequently asked questions
How do I validate a startup idea without building anything?
Put the promise in front of real buyers and make them take a costly action: join a waitlist with intent, book a call, or pre-pay. Talk to ten people who have the problem and listen for what they already do about it. If nobody acts when it costs them something, the idea is not validated no matter how much they say they like it.
How many customer interviews do I need before building?
Ten focused conversations with people who genuinely have the problem is usually enough to see a pattern. You are not after a statistically significant survey. You want to hear the same pain, in the same words, from enough people that you stop being surprised.
What counts as real validation versus a false positive?
Real validation is a costly signal: money, a booked meeting, a switch away from their current tool. Compliments, likes, and 'I would totally use that' are false positives. If the only evidence is that people were nice to you, you have not validated anything.
