How to Validate a Startup Idea Before You Build the App

Turn the idea into a testable statement

Try this structure: “We believe [specific customer] struggles with [specific problem] during [specific situation]. They currently use [alternative], which creates [cost or frustration].”

For example: “We believe independent tutors lose time tracking schedule changes across chat messages and spreadsheets.” That is a hypothesis. You still need to find out whether the problem happens often and matters enough to change behavior.

Ask about the last time it happened

Speak to people who fit the customer description. A first round of five to ten interviews can help you improve your questions; it cannot establish market-wide demand.

Ask: When did this last happen? What did you do? How long did it take? Who else was involved? Have you tried to solve it? What made previous options disappointing?

Avoid opening with a product pitch. “Would you use my app?” invites guesses and encouragement. A recent example reveals actual behavior.

Test the service manually

For the tutor example, you could offer to coordinate schedules for a small number of tutors using existing tools. Track how they use the service, what requires intervention, and whether they want to continue.

This can reveal value before custom software exists. It also reveals operational work that a prototype might hide.

Define your decision before seeing the results

Choose what evidence would justify another experiment. An illustrative rule might be: “If three of five suitable testers use the service again next week, we will test a paid version.” That is your experiment's decision rule, not a universal benchmark.

Track compliments separately from commitments. Agreeing to another call, sharing relevant data, introducing a colleague, or participating in a paid test can each tell you something different.

Use a one-week discovery sprint

Spend the first day defining assumptions and finding interviewees. Use the next three days for conversations. Build and run a small test during the remaining days, then review what changed in your understanding.

Recruitment may take longer. Keep the experiment narrow rather than forcing a conclusion to fit the calendar.

Next step: Write down the assumption that would make your idea collapse if it were false. Test that one first. Read the MVP guide in this collection when you are ready to turn your findings into a product experiment.