How to validate an app idea before building

Name the assumption that could sink the idea

Validation means collecting evidence about a specific uncertainty. A polished landing page, a high AI score, or a friend saying ‘I would use that’ does not answer every question about a product. Start by writing what must be true for the idea to work.

For a tool that turns client feedback into a task list, your assumptions might be that feedback is regularly lost, that designers spend time reconciling it, and that they would change their process. Choose the assumption with the largest consequence if it is wrong. Test that before building the most interesting feature.

Ask about the last time the problem happened

Speak with people who actually do the task. Ask for a recent example before explaining your proposed solution. Concrete behavior is easier to examine than a prediction about what someone might buy in the future. If they can show you an existing workaround without exposing private information, that can reveal steps an interview alone misses.

Keep notes in the person’s words. Separate what you observed, what they reported, and your interpretation. A small set of conversations helps you discover patterns and contradictions; it is not a statistically representative market study. Include people outside your immediate circle when you can.

• When did this last happen, and what triggered it?
• Walk me through what you did next.
• What did the workaround cost in time, money, or missed work?
• What have you already tried, and why did you stop using it?
• Who decides whether a new tool can be used?

Test the outcome with the smallest honest experiment

You do not always need software. You might manually create the promised summary, demonstrate a clickable prototype, or ask someone to try one functioning workflow. Explain what is manual and what is automated. Do not present a waitlist as an available product or collect information you do not need.

Before running the experiment, define a decision. For example: ‘I will invite five designers who recently had this problem. I will continue to a prototype if at least three provide a real feedback list and use the resulting summary in a handoff.’ These numbers are an example decision rule, not a universal benchmark. Adjust them to the cost and uncertainty of your project.

Keep an evidence log, including the bad news

Record who the experiment was for, what you offered, what they did, and what you learned. A sign-up indicates interest in the offer as presented. Repeated use indicates something different. Payment can be stronger evidence of willingness to pay, but only when people understand what they are buying and what you will deliver.

Look for reasons to change your mind. If people like the idea but will not share an example, try the workflow, or introduce the person who owns the task, ask what blocks them. They may face a real permission problem, or the task may simply matter less than you thought. Either answer helps you decide what to test next.

Assumption: designers lose track of feedback.
Evidence: [a dated, specific observation]
Counter-evidence: [what does not fit]
Next test: [one action and participant group]
Decision: [continue, narrow, change, or stop — and why]

Where the Idea Checker helps — and where it stops

The Idea Checker reads the description you submit. Jev answers 75 structured questions, and the site turns those answers into a readout. The numeric build-readiness score combines seven core criteria with 60 detail criteria; the remaining questions provide context. The core and detail portions each account for half of the score when enough answers can be scored.

Missing information and low-confidence answers affect coverage. The checker does not interview customers, browse competitors, or verify your claims. A clear description can earn a strong score before any demand has been proven. Use the result to improve your brief and decide what evidence to collect, then return to your validation log.