How to Validate a Startup Idea Before Writing Code
Practice3 minInnovialabs editorial team
In short
Test behavior, not opinions: talk to potential customers about their problem, then give them a chance to sign up or pay — all before a single line of code is written.
The short answer: what "validating an idea" means
Validating an idea means getting proof that people really want this problem solved and are willing to give something for it: time, contact details or money. "Cool idea" from friends is not proof. You need actions from potential customers.
The good news: you almost never need a finished product for this. Below are four methods, from the cheapest to the more involved.
Method 1. Customer interviews
The goal of an interview is to understand the problem, not to sell a solution. Talk to people from your target audience and ask about past experience, not future intentions.
Good questions:
- When did you last run into this problem?
- How do you solve it today?
- What annoys you most about the current solution?
- How much time or money does it cost you?
Bad questions: "Would you use an app like this?", "How much would you pay?". People answer those politely, not honestly.
Success signal: the problem is recurring and painful, and people already spend effort or money on it.
Method 2. Landing page test
Build a one-page site that describes the product as if it already exists: problem, solution, benefits and a call to action — "Request access", "Join the waitlist", "Get pricing".
Then drive traffic to it: ads, niche Telegram channels, communities. Look not at page views but at conversion to action: how many visitors left their contact details.
You can build several versions with different positioning and compare which message resonates best.
Method 3. Pre-sales
The strongest signal is money. Offer to sell the product in advance: at a discount, as a pre-order or as a pilot contract for B2B.
- For B2C — prepayment or a deposit for early access.
- For B2B — a letter of intent or a paid pilot.
If people pay for something that does not exist yet, demand is confirmed far more reliably than by any survey. Be honest about timelines and refund terms.
Method 4. No-code experiments
Sometimes value has to be shown in action. Assemble a working version without programming:
- website and form builders to collect requests;
- spreadsheets instead of a database;
- a Telegram bot built with a ready-made builder;
- manual work behind the scenes — the "Wizard of Oz" approach, where the user sees a service and you run the process by hand.
This tests not only demand but the scenario itself: is it clear, where do people get stuck, what do they actually need.
How to choose a method
| Method | What it tests | Cost |
|---|---|---|
| Interviews | Whether the problem exists | Time only |
| Landing page | Whether the solution is interesting | Low |
| Pre-sales | Whether people will pay | Low |
| No-code | Whether the scenario works | Medium |
They are usually done in order: problem first, then interest, then money.
Common mistakes
- Asking only people you know. They do not want to upset you.
- Falling in love with the solution. Test the problem; the solution can change.
- Not setting a success criterion upfront. Decide before the experiment what result counts as confirmation.
- Ordering development right away. Code is the most expensive way to test a hypothesis.