A field guide for independent builders

Where to Find App Ideas People Might Pay For

Look in your own repeated work, feedback on existing products, open-source issues, communities for a specific job, and search queries. Start with a task someone already struggles to complete, then find out whether a small improvement is worth paying for.

By TopTrending · Published · Reviewed

Browse software research leads Research your own term

Looking for a coding exercise? Choose a project around a skill you want to practice. This guide focuses on commercial research; a worthwhile learning project does not need a paying customer.

Five places to find app ideas

Choose a source close to a user you can reach. Keep the original observation separate from your proposed solution. The table describes a research method, not proof that any source contains a profitable idea.

Where to look, what to record and the limits of each signal
SourceWhat to look forWhat to recordWhat it can showWhat it cannot prove
Your own repeated workA task you repeat in spreadsheets, email, copy-and-paste steps or a small script.Who does it, the trigger, the input, the output and how often it happens.A workflow you can inspect and reproduce.Your experience alone does not establish that other people have the same problem or will pay.
Feedback on existing productsSpecific requests, support discussions and reviews describing a task that remains awkward.The original link and date, the user's context, the requested outcome and the existing workaround.A reported friction and an existing alternative to investigate.A complaint does not prove repeated demand, a missing feature or willingness to switch.
Open-source issue trackersBug reports, recurring configuration problems and feature requests in a relevant project's issues.The issue, maintainer response, available fix and the workflow affected. Check whether it is still unresolved.A concrete technical problem and the project's response.An issue is not automatically a SaaS opportunity. A fix may already exist, and users may expect it for free.
Communities for a specific jobPeople describing how they complete a task in a profession or small business.The role, repeated questions, current tools and people you could respectfully ask about their process.Language and context for a buyer interview.Upvotes and a single discussion do not establish a market. Do not infer a commercial need from popularity.
Search queries and trend signalsTask-specific searches and the tools, tutorials or comparisons returned for them.The query, intent, competitors and any metric's source, date and country.A research lead and a view of existing supply.Search volume is not your reachable customer count. Growth and low KD do not prove an easy market.

GitHub documents how issues track work and feedback. Read the discussion and any linked fix before interpreting an issue as unmet demand.

Look for repeated work, not just interesting concepts

Ask a potential user to walk you through the last time the task happened. What triggered it? Which files, emails or tools did they use? What had to be copied, checked or corrected? Ask how often the task recurs and what happens when it goes wrong.

Keep an evidence note with the original link or a consented account of the process, its date and the user's role. A spreadsheet or manual script is a clue to investigate. It might also be a good enough solution. If you cannot find a current workaround or repeated examples, leave the need unconfirmed.

Turn one observation into a small product hypothesis

Select and copy this card into your notes. Fill it with observed evidence and explicit questions. Write “unknown” when you lack an answer; the card does not calculate a success score.

Target user:
Repeated task and trigger:
Current workaround and its cost:
Existing alternatives:
Unanswered questions and missing evidence:
One core action (input → useful output):
Next experiment and what would make us stop:

Keep the core action concrete: one input, one useful output. “Review a weekly feedback digest” is easier to test than “build an AI product-management platform.”

A worked example: scattered product feedback

Suppose a small team reviews feedback arriving by email. A weekly digest linked to the original messages is a possible experiment. The team's email workflow is an illustrative assumption: this example reports no customer interviews, measured time savings, revenue or confirmed willingness to pay.

Product Feedback

Public sources reviewed . This is a worked research example, not a validated business.

Observed public evidence
The public record describes collecting, grouping and acting on user requests. It treats scattered comments as a starting point for a workflow investigation. Read the public keyword record.
Existing supply
Canny already offers customer feedback capture, organization and a customer-facing portal. Basic feedback collection is existing supply, not an unclaimed product category. Canny's official product page.
Hypothesis to test · editorial inference
For a small SaaS team receiving feedback by email, a weekly digest that links each theme back to the original message might reduce manual review. This is a product hypothesis, not a verified gap in Canny or other products.
Next validation action
Ask teams to show their current feedback review. Try a manually prepared digest with permission, compare it with their existing tools, and ask whether the result is useful enough to buy repeatedly.

No search-volume, growth or KD figures are reproduced here. Check the source record's metric date, region and definition before making numerical comparisons; the review date above is not a metric collection date.

Research Product Feedback

The missing evidence is whether a particular team repeats this work, whether its existing tools already handle it, and whether a digest improves the review enough to justify paying. Prepare one manually with permission before building an inbox integration.

Check seven signals before building

Use these questions to find missing evidence, not to certify an idea. Record an observation, an unknown or a reason to stop for each one.

  1. 1. A repeated problem

    Does the task recur? Ask to see recent examples instead of relying on a general complaint.

  2. 2. An existing workaround

    What spreadsheet, email chain, manual service or script already gets the job done? If none is evident, leave the need unconfirmed.

  3. 3. A meaningful failure cost

    What happens when the task is late or wrong? Record the user's own explanation without inventing a financial loss.

  4. 4. Active solution seeking

    Do people search or ask for help with this specific task? Read the results to learn what already solves it.

  5. 5. Value visible quickly

    Can a user try one action and understand the output within a few minutes, before complicated setup?

  6. 6. Reachable early users

    Can you identify and contact a small initial group with this problem, with permission and without unsolicited bulk outreach?

  7. 7. One core action

    Can the first test turn one input into one useful output? Reduce the scope before adding accounts, integrations or a full platform.

Choose the next test, not the full product

  1. Ask reachable users to demonstrate a recent instance of the task. Compare what they do with what you assumed.
  2. Offer a small manually delivered outcome or limited pilot. Agree what would make it useful and compare it with the existing alternative.
  3. Seek a concrete commitment, such as a paid pilot, rather than treating compliments or hypothetical pricing answers as proof.
  4. Continue when the problem repeats and users make a concrete commitment. Narrow or stop when the current solution is adequate, the problem is rare or you cannot reach the intended user.

For leads and the longer trend-checking workflow, explore Micro-SaaS ideas. If choosing a research product is the bottleneck, compare Exploding Topics alternatives.

Common questions

What if my app idea is not original?

Start with the user's job and existing alternatives. An established category can still contain a workflow worth investigating, but you need evidence of a useful difference. Renaming an existing product is not that evidence.

Can I enter a market that already has competitors?

Investigate it rather than assuming yes or no. Try the relevant products, ask users what still takes effort, and compare a small proposed outcome with their current solution. Existing products show supply, not an automatic opening for another product.

Where can I find app ideas without paying for a tool?

Start with your own work, public support discussions, relevant open-source issues and communities you already participate in. Google Trends can help inspect relative interest. Paid research is optional; direct evidence of the user's process is still necessary.

How is a practice project different from a business idea?

A practice project is selected to learn a skill and finish a manageable build. A business hypothesis also needs a reachable user, a recurring problem and evidence that the outcome is worth paying for. A useful learning project does not have to meet those commercial tests.

Does a growing or low-KD keyword validate the idea?

No. It can help choose what to investigate. Check the search intent, competitors and data definition, then ask potential users about their current process and test a concrete offer.

Investigate your own seed

Use the words a potential user would search for. This opens keyword research; custom research follows the existing account and credit limits.

Where to Find App Ideas for Your Next SaaS | TopTrending