How to validate a startup idea before you write any code

The cheapest time to find out an idea will not work is before you build it. The most expensive time is six months and a finished product later. Here are five ways to close that gap, roughly in order of cost and effort.

1. Talk to 15 people who have the problem

Not friends, not family — people who actually experience the problem you think you are solving. Ask about their current workaround, not whether they would use your product (people are polite, and that question gets you nothing but false positives). If ten of fifteen struggle to describe the problem in their own words, that is a signal worth taking seriously.

2. Build a landing page and measure intent

A single page describing the product, with a genuine call to action — a waitlist, a deposit, a demo booking — tells you more than a survey ever will. Conversion rate on real traffic is a far better predictor of demand than anything people say in an interview.

3. Run a concierge version by hand

Before writing any code, deliver the outcome manually. If you are building a scheduling tool, book the first few customers' appointments yourself over email. It does not scale, and that is fine — you are testing whether the outcome is wanted, not whether your software works yet.

4. Pressure-test the business model, not just the product

An idea can be wanted and still not work as a business. Would people actually pay what you need to charge? Is the cost of acquiring a customer anywhere near sane relative to what they are worth? These are spreadsheet questions, and they are much cheaper to get wrong on paper than in production.

5. Build the smallest real version and watch behaviour

Once the first four have not killed the idea, it is time for a real MVP — not a prototype, something people can actually use. This is where you learn whether people come back, whether they tell anyone else, and where the product actually breaks down in practice. See our piece on prototype vs MVP if you are not sure which stage you are at.

A rule of thumb

Every step above should be cheaper and faster than the one after it. If you find yourself wanting to skip straight to "build it and see," ask what specifically you expect to learn that the cheaper steps could not have told you. Usually, the honest answer is: nothing you could not have found out for a tenth of the cost.