How to Find an App Idea: 5 Tests Before You Code

To find an app idea, start with a problem people already run into. Look at how they solve it, talk about the last time it happened, and pick a single improvement to test. AI can then help you build a first version. It doesn't replace these checks.

You don't need an idea nobody has ever had: guideline 4.1 forbids copying an app, not solving a problem someone else already tackled. What you need is to understand who your app will help, in what situation, and why that person would want to use it again.

Here are five tests to work through before you ask Codex, Claude Code or an app generator to build your app.

1. Describe a situation, not a pile of features

"A productivity app with AI" is too broad to know what to build.

A more useful sentence looks like this:

When [person] wants to [action], they use [current solution], but [specific difficulty].

Made-up example: when a hiking enthusiast packs their bag, they pull up an old note on their phone, but forget to adjust it to the weather and the length of the hike.

This sentence brings out a person, a moment and a problem. It doesn't prove an app is needed. It gives you something to check.

For your idea, write this sentence without the words "platform," "community" or "revolutionize." If you can't, keep working on the framing before you start building.

2. Look at the solutions people already use

Search for competing apps, but also for everyday solutions: a note, a spreadsheet, a message sent to yourself, a paper sheet.

App reviews can give you questions to explore. A single complaint isn't enough to decide that everyone wants a new app.

Write down three things:

• What the current solution already does well.
• The difficulty that keeps coming up in similar situations.
• The reason someone would stick with that solution anyway.

In the made-up hiking bag example, a simple list may already work very well. The idea is only worth pursuing if you observe a problem that list doesn't solve well enough.

Your first job is to understand that gap. Adding more features doesn't automatically make it bigger.

3. Ask about a real experience

"Would you use my app?" easily invites people to tell you what you want to hear. Ask about what has already happened instead.

You can start with a few people who actually run into the situation. It's not a representative study; it's a way to discover the right questions.

For example:

• When did this problem last happen to you?
• What did you do at that moment?
• What was annoying about that solution?
• Have you ever tried another method?
• What would make you keep your current solution?

Listen for the details and the differences between answers. Someone describing a painful packing session teaches you more than someone who thinks your idea is "cool."

Don't turn three encouraging conversations into proof of a market. If they stay vague or describe different problems, narrow down your audience and redo the framing.

4. Pick a single feature to test

Go back over the conversations and look for the smallest action that could help.

For our made-up example, the first version could let people prepare and reuse a packing list suited to a hike. The social feed, the trail map and the automatic recommendations can wait.

Then write down what you want to observe:

The person manages to prepare their list, understands what they can change, and reuses it for their next hike.

This outcome is more useful than a list of ten screens. It helps you choose what to build and what to test.

My one-page spec template helps you keep that first version short. Once the need is clear, the Codex tutorial or the Claude Code tutorial takes over for the build.

5. Observe an action, then decide what's next

Show how it's meant to work with a sketch, a few screens or a simple enough prototype. Ask the person to do the action you want to make easier.

Watch what happens: do they understand the screen? Do they finish the task? Are they willing to test again in a real situation? Do they come back the next time it's relevant?

These behaviors help you decide. They don't yet prove a subscription will sell.

If your goal is a paid app, also ask what they use today, what they might be paying, and what value they expect. An intention to pay is just an intention until a purchase happens.

Before you put in more time, look at the budget for an iPhone app. An idea can interest users and still be too expensive to run in the form you planned.

The worksheet to fill out before your first prompt

Copy these lines into a document:

My specific audience:
The situation in which the problem
shows up:
The solution used today:
What's still hard:
What the conversations actually
taught me:
The only feature in my first version:
The action I want to observe during the
test:
What I won't build yet:
The costs I need to check:
What would make me continue, change or
stop:

If several lines are still fuzzy, you know where to keep digging. If they're concrete, you can prepare a small version to test. What comes next is in how to build an app: build the core, plug in payments, publish.

An idea can also evolve after launch. TradaZen started as a trading journal before several product changes. I documented those steps in the TradaZen case study. That journey shows a real evolution; it doesn't guarantee another app's success.

Want to turn your idea into a work plan?

The iOS Kit breaks what comes next into four steps you follow at your own pace: pick the app that can make money, build its core, plug in the money, publish and get found.

Not sure your idea is the right one? The free diagnostic starts from where you are and tells you what to do first.

To move forward with structure, check out the vibe coding course to build your iPhone app with AI.

Frequently asked questions

How do you find an app idea?

Start with a problem people already run into. Look at how they solve it, talk about the last time it happened, and pick a single improvement to test. AI can then help you build a first version, but it doesn't replace these checks. They boil down to five tests to pass before you code.

What's a simple mobile app idea?

A simple idea describes a person, a moment and a specific problem. Made-up example: when a hiking enthusiast packs their bag, they pull up an old note on their phone, but forget to adjust it to the weather and the length of the hike. In this example, a simple list may already work well: the idea is only worth pursuing if you observe a problem the list doesn't solve well enough.

What app can you build as a beginner?

An app that solves a specific problem people already run into, with a single feature in the first version. You don't need an idea nobody has ever had. You need to understand who your app will help, in what situation, and why that person would want to use it again.

How do you validate an app idea before coding?

Pass five tests: describe a specific situation, look at the solutions people already use, ask about a real experience, pick a single feature to test, then observe an action. Don't turn three encouraging conversations into proof of a market. If they stay vague or describe different problems, narrow down your audience and redo the framing. A one-page spec template helps you keep the first version short.

What should you ask people to test an app idea?

Ask about what has already happened: when the problem last came up, what the person did at that moment, what was annoying about their solution. Avoid asking whether they'd use your app, because that invites them to tell you what you want to hear. You can start with a few people who run into the situation: it's not a representative study, but a way to discover the right questions.

How do you know if someone will pay for your app?

Until a purchase happens, an intention to pay is just an intention. If your goal is a paid app, ask the person what they use today, what they might be paying, and what value they expect. Seeing that they understand the screen, finish the task and come back helps you decide, but it doesn't yet prove a subscription will sell.