How to find mobile app ideas worth testing

Collect problems before collecting features.

Keep a small friction log for a week. Whenever a task requires a spreadsheet, a screenshot, repeated copying, or a reminder to yourself, write down who is doing it, what triggered it, and what made it awkward.

Paul Graham’s essay on startup ideas argues for noticing real problems, especially ones you understand firsthand. For mobile products, make that concrete: record the moment and the existing workaround, rather than starting with a broad category such as “an AI productivity app.”

A fictional observation might be: a shift worker compares a rota screenshot with family plans every Sunday. The idea is not yet a calendar app. The question is whether turning that rota into usable availability removes a recurring burden.

Treat reviews as clues, then talk to people.

Read recent reviews of products that serve the same task. Group concrete complaints by situation: setup takes too long, a frequent task needs too many steps, the result is unreliable, or the tool assumes the wrong workflow. Include positive reviews to understand what people already value.

One loud review is not a market. Check whether the complaint is recent, whether it concerns an old version, and whether it appears in independent conversations. A request for a feature is a clue about a problem, not an instruction to build that feature.

Ask someone who faces the problem to walk through the last time it happened. What did they do? What did it cost in time or money? What have they already tried? A real example is more useful than asking whether they like your proposed app.

For the rota example, you might discover the actual obstacle is last-minute changes, not importing the schedule. That would change the product before you write a line of code.

Explain why this should be a mobile app.

Use the phone’s role in the task: a camera at the moment something happens, offline access away from a desk, or a quick action between other activities. If the job is infrequent and mostly involves a large spreadsheet, a mobile app may not be the best first solution.

Then answer four questions: how often does the problem happen, how frustrating is the current solution, where could you reach these people, and why would they switch? Keep evidence and guesses separate. “I saw three people do this” is evidence; “thousands will pay monthly” is still a hypothesis.

Consider the operating cost early too. An AI feature that is easy to prototype may be expensive to run repeatedly. Sketch the value and acquisition economics without treating a spreadsheet forecast as validation.

Build the smallest test that can change your mind.

Choose the riskiest assumption. If you doubt people understand the benefit, test a clear explanation and a clickable flow. If you doubt the output is useful, produce it manually for a few willing participants. If you doubt they will return, test the workflow across repeated real occasions.

For the rota idea, a small test could turn a participant-provided, redacted sample into an availability view. Observe whether they can use it to make plans, then whether they ask to use it with the next rota. Be clear about what is manual and what actually exists.

Decide in advance what would make you continue, revise, or stop. Compliments and waitlist signups show different levels of commitment from repeated use or a real purchase; none alone proves a durable business.

Once a small version exists, track the moment it delivers value. The useful output of idea discovery is a specific next test, not a longer list of app categories.