How to validate an app idea before you build

Validating an app idea means gathering enough evidence to decide what to do next. You are trying to understand whether a particular group has a problem worth solving, whether your proposed approach helps, and whether people will make room for it in their existing routine.

You can investigate much of this before building a working app. Conversations, examples of current work, a simple page, or a manual trial may answer the most urgent question sooner.

Consider a hypothetical tool for freelance translators who need clients to approve translated files. The initial idea is a portal where each job has one current file and a clear approval status. The first task is to find out whether that problem deserves a portal at all.

“Translators need better project management” is too broad to investigate. A more useful starting assumption is: freelance translators lose track of which file a client has approved when feedback is scattered across email threads.

That statement names a person, a situation, and a problem. It may still be wrong. Perhaps the real difficulty is agreeing the scope before work begins, or perhaps an existing email habit already works well.

Write down the decision the research should inform. For this example: should you explore a shared approval page, improve the existing handoff process, or leave this problem alone? Keep a short list of assumptions that would change that decision. You do not need a complete product specification yet.

Speak to people who actually do the work. Ask them to describe the last job where approval was unclear, rather than asking whether they like your idea.

Useful questions include:

• What happened from sending the file to receiving approval?
• Where did you look to find the latest version?
• What did you do when the answer was unclear?
• Who else had to participate?
• What have you already tried to improve this?

Ask to see a redacted example or a walkthrough using dummy material if that helps explain the process. Avoid collecting confidential client documents.

Look for differences between people as well as recurring patterns. A translator with one long-term client may have a different problem from someone handling many short projects. That difference can help you narrow the audience instead of adding features for everyone.

Your alternative is not always another app. It may be an email subject convention, a shared folder, a spreadsheet, or asking a colleague to check.

Find out what people value about that arrangement. Email may be messy but familiar to every client. A new portal might organize files while introducing an unwanted account and another place to visit.

Look at existing products to understand how the task is already served. Do not treat competitors as proof that your version will attract users, or their absence as proof that the idea is wrong. Compare the actual experience people describe with what you are proposing.

For the translation example, the key question may become whether a clearer approval page helps enough to justify changing the client's handoff routine.

Build only what you need to learn something useful. Different unknowns call for different experiments.

These experiments are not interchangeable. A page can test whether an offer is understandable and attracts interest; it cannot show whether people will continue using an unfinished product.

In Mythos, you can build a focused prototype and inspect it in Preview. Plan mode can help you define that small scope. Keep the experiment's question in view so a prototype does not quietly expand into a full application.

Tell participants whether they are seeing a concept, a prototype, or a working service. If you are manually organizing files behind the scenes, say so. Use fictional documents while testing the interface.

Choose a next step that matches the stage. A relevant person agreeing to walk through their current process gives you different evidence from someone volunteering for a trial. A compliment or a broad “I would use this” is worth recording, but it is not the same as making time to try it.

If you publish a landing page, describe what is available now and what you are inviting people to do. A waitlist should be a real waitlist with a working submission route. The website building guide covers making that visitor action work.

Avoid fake testimonials, invented usage numbers, or implying that a feature already operates. Those shortcuts make the response harder to interpret and damage the trust you need for further research.

Before the experiment, write down what would lead you to continue, narrow the idea, change the approach, or stop. Use criteria suited to your audience and the commitment you are asking for; a universal conversion target would hide those differences.

Afterward, separate observations from explanations. “Two participants could not find the approval action” is an observation. “Clients do not want an approval portal” is a much broader conclusion that the observation may not support.

Check whether you reached the intended audience and whether participants understood the offer. Poor reach, unclear wording, a confusing interface, and a weak underlying need call for different responses.

Keep a short record of what you learned and what remains uncertain. If the evidence justifies a working trial, move to building an MVP with one audience and one complete task. The next version should answer the next important question, not every question you can imagine.