How to Validate a Startup Idea Before Writing Code (2026)
The cheapest insurance against shipping into silence is validating the idea before you build it. Five small experiments, what each one tells you, and how to read the result honestly.
Posted by
RouzbehRelated reading
How to Add a TestFlight Beta Waitlist to Your iOS App (2026)
A TestFlight beta waitlist is the cheapest way to filter who gets in before you hit Apple's 10,000-tester cap. How to set one up, what two questions to ask on the form, and how to invite people from the list.
Best Product Feedback Tools for Indie Founders (2026)
Best product feedback tools for indie founders in 2026: Canny, Featurebase, Nolt, Frill, Sleekplan and Lighthouse compared on price and fit for a small product.
Waitlist with a Survey: Why Answers Beat Emails (2026)
A waitlist with a survey tells you who signed up, what they want, and what they would pay, before you write a line of code. Why an email-only list is a vanity metric, what questions to ask, and how to read the answers.
Validating a startup idea before writing code is the cheapest insurance against shipping into silence. You design a small experiment, run it for two or three weeks, and find out whether real people, in their own words, want what you are about to build. If the answer is yes you save months of speculative work. If the answer is no you save a quarter of your year.
I have shipped 7 indie apps over 8 years. The pattern is embarrassingly consistent: the ones I validated first turned into real products, and the ones I did not turned into expensive lessons. This is what I would tell past me to do instead.
Table of contents
What "validation" actually means
Validation is not asking your friends if it sounds cool. It is not counting likes on a tweet. It is finding evidence that strangers, who match your target customer, will pay attention, give you their email, or hand over money for a thing that does not yet exist. The evidence has to come at some cost to them. A click is the cheapest signal; money is the strongest. Anything in between is a useful middle.
The point of validation is not to confirm that your idea is good. It is to find out whether you are wrong before it costs you three months. The mindset shift that matters: you are trying to disprove the idea, not defend it.
The cheapest validation is the one you run before you fall in love with the answer.
Signals that prove demand, and signals that fool you
Not all data is equal. Some signals lie to you because they cost nothing to give. Here is how I rank them after seven launches:
| Signal | Cost to the giver | How much you should trust it |
|---|---|---|
| A "that sounds cool" comment | Zero | Almost none. People are being polite. |
| A like or upvote | One click | Slightly more than nothing. Mostly vanity. |
| An email on a waitlist | Real attention + privacy cost | Real signal, especially with a survey attached. |
| A detailed survey answer | 2 to 3 minutes of focus | Strong. People do not write paragraphs for fun. |
| A pre-order or a paid commitment | Money | The strongest signal you can collect. Trust it most. |
A handful of pre-orders beats a thousand likes. A survey answer that names a specific pain in the customer's own words beats a generic "I would use this". Optimise the experiment for the strongest signal you can realistically capture in your time and budget.
Five low-effort experiments to run
You do not need a working product. You need a small experiment that answers one specific question. Here are five I have actually used, ranked from cheapest to strongest signal.
1. The waitlist with survey questions
Put up a one-page landing site. Ask for an email and 2 or 3 survey questions on the same form: what they use today, what is most annoying, what they would pay. Drive a few hundred visitors to it from one channel. The signups give you a list; the answers give you the language for your product page and your roadmap. Read more in why a waitlist with a survey beats email-only.
2. The manual MVP
Do the work the product would do, by hand, for 5 or 10 people. They do not need to know you are doing it manually. A personalised newsletter you write yourself. A "summarise these PDFs" service where you read them. The point is to find out whether the output is valuable enough that people will keep coming back. If they do, you have a product to automate. If they do not, no amount of engineering would have helped.
3. The concierge test
Like the manual MVP but you tell them. You charge a small amount up front and deliver the result over email or a shared doc. The commitment is real, and you learn faster because you have to talk to the customer at every step. Three concierge customers will teach you more than three months of building.
4. The static prototype
A clickable mockup, in Figma or as a static HTML page, with a "Get notified" button on every action. You watch which buttons get clicked, ask the user what they expected to happen, and confirm whether the mental model in your head matches theirs. Cheap to build, very honest about feature priority.
5. The paid pre-order
The strongest validation you can run. A landing page with a clear price, a buy button, and a delivery window ("ships in October"). Promise refunds if you do not ship. Even 10 pre- orders is a far stronger signal than 1000 waitlist emails, because money replaces every other kind of social politeness.
Most indie founders should run number 1 first, then a slice of number 2 or 3 with the most engaged signups. Number 5 is the senior move, run only after you are confident the audience exists.
How to design the experiment so the result is honest
Bad experiments fool you. A waitlist behind a paid ad to your own audience is a vanity test. A survey on Twitter is biased toward people who already like you. Three rules for honest design:
- Ship the experiment to strangers, not friends. If you have a personal network, exclude it. A signup from your cousin's coworker is not the signal you want.
- Pre-decide the threshold for "yes". Before you start, write down what would make you confident enough to build. 100 signups? 5 pre-orders? 20 detailed survey answers? Post-hoc rationalisation is the most common founder error. If you set the bar later, you will move it.
- Drive traffic from one source you can describe. One subreddit, one newsletter, one cold-email batch. Mixing sources makes the signal unreadable.
For the actual page setup, the longer guide to building a waitlist walks through the wiring; the product survey guide covers question wording.
How long to validate before deciding
The risk of running too long is you get attached and rationalise mediocre data. The risk of running too short is you bail on a real signal. Some rough timelines based on the experiment:
| Experiment | Run time | Cost to you | What you should learn by the end |
|---|---|---|---|
| Waitlist with survey | 2 to 4 weeks | An afternoon to set up + traffic cost | Whether the audience exists and what they want |
| Manual MVP | 4 to 8 weeks | Hours per week per customer | Whether the output is valuable enough to repeat |
| Concierge test | 2 to 6 weeks | Hours of your time + emotional labour | Whether people will pay for the output now |
| Static prototype | 1 to 2 weeks | A few days of design | Whether the flow matches their mental model |
| Paid pre-order | 2 to 4 weeks | Pricing nerves + refund handling | Whether anyone will pay at the price you imagined |
If 4 weeks of one of these tells you nothing definite, the answer is probably soft no. Soft no is still useful information.
When the answer is no, what to do next
Most ideas do not survive validation, including the good ones. Three moves I have found useful when the result comes back weak:
- Talk to the 5 most engaged signups. Even a soft no leaves a handful of people who said yes loudly. Call them. There is often a real product hiding inside their reason, just not the one you started with.
- Change the audience, not the product. Your feature set might be right and your buyer might be wrong. Indie SaaS in particular often needs only a swap of audience to start working.
- Take the lesson and move on. The fastest indie founders I know are the ones who can drop an idea in week 3 and start the next experiment in week 4. Sunk cost is the real productivity killer.
If the answer comes back yes, the natural next step is getting your first 100 users. That post picks up where this one ends.
Common validation mistakes
- Validating with your audience instead of theirs. If you have a Twitter following of indie devs and your product is for school principals, your own audience tells you nothing.
- Measuring intent without cost. "Would you use this" is the wrong question. "Here is an email field" or "here is a price" is the right one.
- Treating one viral spike as validation. A single hit on Hacker News is not validation; it is a sample of a single audience on a single day. Sustainability is the signal.
- Building the validation page for two months. If the experiment takes longer than the build it is meant to prevent, you have lost the plot. Cheap and ugly is the whole point.
Watch: validating an idea before building
If you would rather see the idea explained, this short video covers a pre-launch validation step for indie projects:
Frequently asked questions
How do I validate a startup idea before writing code?
Pick one small experiment that asks strangers for something real: an email on a waitlist with survey questions, a paid pre-order, or a manual delivery of the output the product would produce. Run it for 2 to 4 weeks against an audience you do not personally know. Use the result to decide whether to build, change audience, or drop.
How many signups or pre-orders count as validation?
There is no universal number. A few rules of thumb for indie products: under 20 waitlist signups in a few weeks is weak signal and probably traffic, not interest. 50 to 100 with detailed survey answers is a real starting audience. 10 paid pre-orders at a real price is stronger than 1000 emails.
Should I validate with cold traffic or my own audience?
Cold, every time. Your audience is biased toward you, not the product. The validation question is whether strangers who match your buyer profile will engage. If you only have an own-audience signal, treat the result as encouraging but not conclusive.
Can I validate without a landing page?
Yes, but it is harder. Concierge tests and manual MVPs do not need a public page; they need a small list of strangers to talk to and something concrete to sell or deliver. A landing page is just the most repeatable way to do the same thing.
What if I am too early-stage to know the price?
Ask about effort instead. "How much time would this need to save you for it to be worth $20 a month" is a real pricing proxy without forcing a number you cannot back up yet.
Validation is not a stage you finish. It is a habit. Every feature on the roadmap deserves the same small experiment treatment that the founding idea did. The founders who keep their products alive for years are not the ones who are right more often, they are the ones who learn they are wrong faster.
Lighthouse gives you the waitlist with survey questions, the newsletter for keeping the list warm, and the feedback page for after you launch, in one place. Free trial, indie pricing. From an indie dev, for indie devs and makers.