How to validate a startup idea before you build anything

Most products don't fail because the code was bad. They fail because nobody needed them badly enough to pay. AI tools have made building faster and cheaper for everyone, which means the real advantage has shifted: knowing what not to build is now worth more than building quickly.

Here is the process we use before writing a line of code, on our own products and with the founders we partner with.

1. Name one customer you can reach this week

"Small businesses" or "people who want to save money" is not a customer. A customer is specific enough that you could find ten of them by Friday: independent dental clinics in Florida, parents of children who use picture boards to communicate, overland travellers who drive remote routes.

If you can't name them, you can't talk to them, and the rest of this process stalls.

2. Find out how they solve the problem today

Every real problem already has a solution, even if it's a bad one. People use spreadsheets, sticky notes, WhatsApp groups, an expensive tool they half-like, or they simply put up with it.

• If they pay for an alternative, there's proven demand. Your job is to be meaningfully better for a specific group.
• If they use workarounds, the pain is real but nobody has solved it well yet. That's often the best opportunity.
• If they do nothing, be careful. The problem may not hurt enough to change behaviour.

3. Talk to at least ten potential customers

Ask about their problem, not your idea. Good questions:

• When did this last happen? What did you do?
• What have you tried? Why didn't it work?
• What does it cost you in time or money?
• If this disappeared tomorrow, what would change?

Avoid asking "Would you use an app that…?" Almost everyone says yes to be polite. Past behaviour tells you far more than predictions about the future.

4. Ask for a real commitment

Interest is cheap. Commitment is evidence. In rough order of strength:

1. Joining a waitlist with their real email
2. Agreeing to a follow-up call to see a prototype
3. A letter of intent from a business customer
4. A deposit, a pre-order or a paid pilot

If people won't give you a small commitment now, they're unlikely to pay later.

5. Write down the one job your first version does

Your first version should do one job for one customer very well. Write it in a single sentence. Every other feature goes on a list that waits for evidence from real users.

When we built Finvex, months of hands-on beta testing shaped which features made the cut. The roadmap came from what testers actually asked for, not from a feature list written in a meeting.

6. Decide who owns sales

This is the step most technical founders skip. Someone needs to own finding customers from day one, while the product is being built, not after it launches. Products with a clear sales owner learn faster, because they have real users giving feedback sooner.

What a good validation result looks like

You're ready to build when you can say:

• We know exactly who the customer is and how to reach them.
• We've spoken to enough of them to see the same pain repeatedly.
• Some of them have committed something real.
• We know the one job the first version must do.
• We know who will sell it.

If you can't say all five yet, that's not failure. It's the cheapest possible time to find out, and every answer will shape what you build.

Want a quick read on where your idea stands? Take our free Idea Validation Scorecard. It takes two minutes and tells you exactly what to test next.