How to find app ideas worth building

Start with a repeated inconvenience

A useful app idea often starts with a task someone already does badly: copying information between two tools, reminding a group about the same thing, or keeping a spreadsheet that only its creator understands. Look for the workaround before imagining the interface.

Write down who does the task, what triggers it, how they handle it today, and what goes wrong. ‘An app for freelancers’ is a market label. ‘A designer manually checks which client feedback is still unresolved before every handoff’ is a problem you can investigate. The second description gives you someone to talk to and an outcome to test.

Three places to look for your next project

Start with your own recurring tasks, then observe a workflow you can access through work, a hobby, or a community. Ask permission before looking at someone else’s files or business process. Public requests and an app-idea board can broaden your options, but a request is a lead to investigate, not proof of a market.

On this board, browse a category you understand, open an idea, and read the full description before copying its build prompt. Likes and prompt copies show activity on the board; they do not establish willingness to pay. A quiet idea can still fit a specific audience you know how to reach.

• Your own week: which task did you repeat, postpone, or redo?
• Someone else’s workflow: where do files, messages, or responsibilities get lost?
• Public ideas: which request describes a concrete user and an observable result?

Compare ideas before choosing one

Make a shortlist of three. For each, record an example of the problem, a person you can contact, a small useful outcome, and the hardest dependency. An idea that needs a private dataset, several external approvals, or a two-sided marketplace has more things to resolve before a first test.

Prefer the idea for which you can learn something soon. If you cannot reach a likely user, your first task is finding that person. If a spreadsheet already solves the problem well, identify what your version would improve enough to justify switching. Do not add AI merely to make the concept sound different.

Example: turn a broad idea into a testable one

Consider a hypothetical ‘productivity app for creatives’. Narrow it to freelance designers collecting feedback on a single deliverable. Their current workaround might be a document plus scattered messages. The first version could accept a pasted feedback list, attach an owner and status to each item, and export an unresolved-items summary.

Leave automated integrations, team billing, and a mobile app out of the first version. Ask a designer to use the small workflow on a real handoff. Observe whether they return to the summary and whether any important feedback is missed. This is an illustrative concept, not a claim that customers have validated it.

Leave with a one-paragraph brief

Use the template below to make your assumptions visible. Keep facts separate from guesses. If you do not know how often the problem occurs, say so rather than giving it an invented frequency. The brief should tell a builder what success looks like without prescribing every screen.

You can post an idea on the board without an account, browse existing ideas, or use the Idea Checker to find missing details in your description. Posting is public and permanent, so omit secrets and private client information. A generated prompt gives you a starting specification; you still need to test the problem with people.

For [specific user], when [situation], the current workaround is [method]. It causes [observable problem]. The first version will let them [one outcome]. I have evidence from [actual observation, or ‘not tested yet’]. I will test it by [next action].