How many customer interviews do I need to validate an idea?

Ten to fifteen conversations with people who genuinely have the problem is usually enough to see clear patterns. You are looking for consistency: if most people describe the same painful workaround unprompted, the problem is real. Quality matters more than count — one honest interview with a real sufferer beats ten polite ones with the wrong audience.

Do I need to build the product to validate the idea?

Not at first. Interviews and a simple landing page or pre-sale can validate the problem and demand before you build anything. Build a real MVP only once those cheaper tests point the same way, and even then build the smallest version that delivers the core value so you can watch how real users behave.

What is the difference between validating the problem and validating the product?

Validating the problem proves that a specific group of people has a painful, frequent need worth solving. Validating the product proves that your particular solution actually gets used and paid for. You do them in that order, because a great product for a problem nobody has is still a failure.

How do I test demand cheaply in India?

Use the channels people already live in. A WhatsApp broadcast to a relevant community, a post in a niche group, a landing page with email capture, or a small UPI-based pre-order all generate real signal for very little money. The metric that counts is action — a reply, a sign-up, or a payment — not views or likes.

When should I actually start building the MVP?

When your interviews confirm a real, urgent problem and a demand test shows strangers will raise their hand. At that point a working MVP that lets a real user complete the core job is the next validation step. Tools like Kashvi let you put a real, usable app in front of those users quickly so you can measure behaviour instead of opinions.

What signals mean my idea is validated?

Repeated, unprompted use by real users, people willing to pay, and users who are genuinely frustrated when the product is unavailable. Friendly feedback, one-time curiosity sign-ups, and social likes are not validation. If you see people returning on their own and referring others, you have real evidence.

Article

How to Validate a Startup Idea

Most startup ideas fail not because the code was bad, but because nobody wanted the product. Validation is the work you do before and during building to make sure you are solving a real problem people will pay for. It is not a formality or a survey you send once. It is a series of small, cheap tests that either build your confidence or save you months of wasted effort. This guide walks through how to validate a startup idea properly, in an order that reduces risk step by step.

Validation has one goal: replace your assumptions with evidence. When you have an idea, you are really making a stack of guesses — that a specific group of people has a specific problem, that they want it solved badly enough to act, and that they will choose your solution over what they do today. Each guess can be wrong, and each wrong guess kills a startup. The job is to find the wrong guesses fast and cheaply, while they still cost you a conversation instead of a launch.

Start with the problem, not the solution

Founders fall in love with their solution and forget to check whether the problem is real. Before you write a line of code, write down the problem in one plain sentence, name exactly who has it, and describe what they do about it today. If the honest answer is that they do nothing, or that the workaround is good enough, that is a warning sign. The strongest startups replace a painful, frequent, expensive workaround — a messy spreadsheet, a WhatsApp group that loses orders, hours of manual copy-paste.

Talk to real people before you build

Customer interviews are the single highest-value validation step, and the one most founders skip. Aim for ten to fifteen conversations with people who actually have the problem. Do not pitch. Ask them to walk you through the last time they faced it, what they tried, and what it cost them in time or money. Ask about the past, not the future — what someone did last week is data, what they say they might do is a wish. If nobody can recall a recent instance of the pain, the problem may not be urgent enough to fund a business.

Ask 'when did you last deal with this?' instead of 'would you use an app for this?'
Listen for the workaround they already pay for — that is your real competitor.
Note the exact words they use; they become your marketing copy later.
Watch for people who ask 'can I use it now?' — that is genuine demand, not politeness.

Test demand before you test the product

You can measure interest without a finished product. A simple landing page that describes the offer and asks for an email or a small pre-order tells you whether people will lean in. A short WhatsApp broadcast to a community, a post in a relevant group, or a UPI-based pre-sale for a niche product all generate real signal. The metric that matters is action: sign-ups, replies, deposits. Views and likes are cheap; a phone number or a payment is a commitment. If you cannot get a handful of strangers to raise their hand, more features will not fix that.

Test	What it costs	What it proves
Customer interviews	A week of conversations	The problem is real and urgent
Landing page + email capture	A day to set up	People want to hear more
Pre-sale or paid waitlist	A payment link	People will actually pay
Working MVP with real users	A focused build	People use and keep using it

Build a real MVP only when the signals justify it

Once interviews and demand tests point the same way, build the smallest version that delivers the core value — nothing more. The mistake here is building a beautiful full product to test one assumption. An MVP should let a real user complete the one job that matters and let you watch what they do. Do they come back? Do they invite others? Do they ask you to fix the thing that is missing? That behaviour is the truest validation of all, because it is people voting with their time.

This is the stage where speed compounds. The faster you can put a working app in front of real users, the more validation loops you run before you run out of money or motivation. Kashvi is built for exactly this loop: describe your app in plain English and it builds a real, working product — a real Postgres database, real user sign-up and login, a live preview, and full code you own with no lock-in. It builds web apps and real Android and iOS apps via React Native, so you can hand a working link or an app to the people you interviewed and see what they actually do. Because billing is transparent and credits are refunded when an AI generation fails, testing an idea does not mean burning cash on a big agency build before you know it works.

Validation is not a phase you finish. Keep talking to users after launch — the questions just shift from 'is this a real problem?' to 'why do people stop using it?'

Read the signals honestly

The hardest part of validation is being honest with yourself. Polite encouragement from friends, a spike of curious sign-ups that never return, and a few kind emails can feel like traction while proving nothing. Look for repeated, unprompted use, people who pay, and users who are upset when the product breaks. If the signals are weak, you have not failed — you have learned cheaply, and you can change the problem, the audience, or the offer and test again. That is the whole point.

Questions

Frequently asked

How many customer interviews do I need to validate an idea?: Ten to fifteen conversations with people who genuinely have the problem is usually enough to see clear patterns. You are looking for consistency: if most people describe the same painful workaround unprompted, the problem is real. Quality matters more than count — one honest interview with a real sufferer beats ten polite ones with the wrong audience.
Do I need to build the product to validate the idea?: Not at first. Interviews and a simple landing page or pre-sale can validate the problem and demand before you build anything. Build a real MVP only once those cheaper tests point the same way, and even then build the smallest version that delivers the core value so you can watch how real users behave.
What is the difference between validating the problem and validating the product?: Validating the problem proves that a specific group of people has a painful, frequent need worth solving. Validating the product proves that your particular solution actually gets used and paid for. You do them in that order, because a great product for a problem nobody has is still a failure.
How do I test demand cheaply in India?: Use the channels people already live in. A WhatsApp broadcast to a relevant community, a post in a niche group, a landing page with email capture, or a small UPI-based pre-order all generate real signal for very little money. The metric that counts is action — a reply, a sign-up, or a payment — not views or likes.
When should I actually start building the MVP?: When your interviews confirm a real, urgent problem and a demand test shows strangers will raise their hand. At that point a working MVP that lets a real user complete the core job is the next validation step. Tools like Kashvi let you put a real, usable app in front of those users quickly so you can measure behaviour instead of opinions.
What signals mean my idea is validated?: Repeated, unprompted use by real users, people willing to pay, and users who are genuinely frustrated when the product is unavailable. Friendly feedback, one-time curiosity sign-ups, and social likes are not validation. If you see people returning on their own and referring others, you have real evidence.

Keep exploring

How to Build an MVP Fast: A Founder's Guide→How to Launch an App in a Weekend→MVP vs Full Product: What to Build First→

Put a real app in front of real users this week

Stop guessing. Describe your idea in plain English and get a working web or mobile app — real database, real login, code you own — to test with the people you interviewed.

Open the studio

Free to start · no credit card