---
title: "Evaluate your app idea"
description: "Find evidence of a valuable problem before expanding the build."
---
An app earns attention by making a meaningful job easier for a particular group of people. Before building a large feature set, look for evidence that the problem is real, repeated, and important enough to change someone’s behavior.

## Begin with observed behavior

Personal experience is a useful starting point because you already know the vocabulary, awkward workarounds, and moments of frustration. It is not proof by itself. Talk to other people who face the same situation and watch what they do today.

-   They spend time, money, or attention on a workaround.
-   They can recall the last time the problem happened without being coached.
-   They have tried another product and can explain why it falls short.
-   They volunteer to test, introduce another user, or ask when it will be ready.

## Measure repetition and consequence

A problem can matter because it happens frequently, because each occurrence is painful, or both. Daily meal planning may be valuable through repetition; emergency coordination may be valuable through consequence. If neither is true, retention will be difficult.

### “I would probably try it.”

_Weak signal_

Interest is polite and costs nothing. It does not predict repeated use.

### “Can I use it for Friday?”

_Strong signal_

A specific moment and request suggest the person already feels the need.

## Picture the first user clearly

“Small businesses” is an audience category, not a product target. “Independent bakers who manage twenty to fifty weekly preorders through direct messages” is specific enough to find, interview, and design for. If you cannot name where the first five users come from, narrow the audience again.

## Watch for ideas that need scale before they work

Marketplaces, social networks, and broad all-purpose tools can appear simple while depending on a large user base, two-sided supply, or expensive distribution. They are not impossible, but a first version needs a useful experience even when only a handful of people have joined.

:::note
Ask: “What value does the very first active user receive?” If the answer depends on hundreds of other people, redesign the opening experience or choose a narrower problem.
:::

## Run a short validation sprint

### 1. Write the promise

Complete this sentence: “For this person, the app turns this difficult moment into this result.”

### 2. Interview five target users

Ask about the most recent occurrence, their current process, its cost, and what they have already tried. Avoid pitching until you understand the behavior.

### 3. Build one complete loop

Use Superapp to create the smallest version that delivers the promised result from start to finish. Leave accounts, sharing, and monetization out unless they are essential.

### 4. Observe unassisted use

Let testers attempt the task without a walkthrough. Record where they hesitate, whether they complete it, and whether they return when the problem happens again.

## Make a decision from evidence

Continue when users recognize the problem immediately, complete the core flow, and ask to use it in a real situation. Narrow or change direction when the value needs a long explanation, testers only praise the visuals, or nobody returns without a reminder.

:::tip
Set the pass condition before testing—for example, “At least three of five bakers use the prep plan for a real order week and ask to keep access.”
:::