The most expensive mistake in software is not a bug. It is building something nobody wanted. The good news: you can find out before you spend real money. Validation is cheap; building is not. Here is how to do it.
The short answer
Before you build, prove three things: the problem is real, it is painful and frequent, and people would pay to solve it. You do that by talking to potential customers, watching how they solve the problem today, and running cheap tests, not by writing code first.
Step 1: Define the problem precisely
Vague ideas like "AI productivity for teams" cannot be validated. Get specific about who has the problem and what it costs them. "Finance managers at 10 to 50 person logistics companies who process 20-plus vendor invoices a week" is something you can go test. The sharper the problem statement, the easier everything after gets.
Step 2: Talk to 20 to 30 real people
Interview people who actually have the problem. Do not pitch your idea; ask about their world:
- How do you handle this today?
- What is frustrating or time-consuming about it?
- Have you looked for a better way? Did you pay for anything?
You are listening for a repeated, painful, expensive problem. The status quo, the workaround people use now, is your real competition. If their current workaround is "good enough," that is a warning sign.
Step 3: Test demand without building
You can measure real interest before writing code:
- Landing-page test. Put up a page describing the solution with a waitlist or pre-order. See if anyone signs up.
- Concierge MVP. Deliver the outcome manually for 5 to 10 users. If people will let you solve it by hand, they will likely pay for software that does it.
- Pre-sales or letters of intent. The strongest signal of all: someone commits before the product exists.
Step 4: Read the signals honestly
Your idea is ready to build when the same painful problem shows up across your interviews, people are already spending time or money working around it, and some of them lean in when you describe a solution. It is not ready when you have to convince people they have the problem.
Where building fits (and where a product simulation helps)
Once the idea is validated, the question becomes how to build without overspending. Jumping straight to a full custom build is where budgets blow up and timelines stretch. A product simulation is the efficient next step: it turns your validated idea into a documented, runnable foundation, the spec, the architecture, a working codebase, and a mock database, in weeks, so you can move toward launch with clarity instead of a blank repo.
Validation tells you whether to build. A product simulation gives you a fast, low-risk way to start building once the answer is yes.
Validated your idea and ready for the next step? Start a project and you will get a clear, flat-rate scope first.
Frequently asked
How many customer interviews do I need?
Aim for roughly 20 to 30 conversations with people who actually have the problem. You are looking for a pattern: the same painful, frequent, expensive problem coming up again and again.
Can't I just build a small version and see if it sticks?
You can, but building is the most expensive way to learn. Interviews, a landing-page test, or a concierge MVP teach you most of the same thing for a fraction of the time and money.
What does validation actually prove?
That a real, frequent, painful problem exists and that people would plausibly pay for a solution. It does not guarantee success, but it removes the most common reason software fails: nobody needed it.