Opportunity discovery guide

How to find software ideas for a solo developer

Good software ideas rarely begin as random feature combinations. They begin with a repeated task, a customer who cares about the outcome, and an opening that a focused product can serve better than broad existing tools.

The short answer

Look for recurring work you understand, then search for signs of friction: manual handoffs, error-prone spreadsheets, repeated support questions, awkward integrations, and broad products that underserve a narrow customer. Prefer opportunities where you can reach the first users and build one complete workflow yourself.

A practical process

Move from an assumption to a decision.

  1. 01

    Start inside a domain you can observe

    Your advantage may be access rather than invention. Work you have done, customers you know, and technical systems you understand make it easier to notice real constraints.

    Do this: List ten repeated tasks you have performed or watched closely during the last year.
  2. 02

    Collect problems, not product pitches

    Record the trigger, current process, frequency, consequence, and workaround. Delay naming the product until the pattern is clear.

    Do this: For each task, note where people wait, copy data, repeat work, make errors, or ask for help.
  3. 03

    Choose a narrow customer

    A specific customer makes product language, feature decisions, pricing, and acquisition more concrete. A broad audience can come later.

    Do this: Replace “small businesses” with a role, situation, workflow, and reason they care now.
  4. 04

    Match the product format to the workflow

    A browser extension suits work that happens in a browser; a mobile app suits in-the-moment use; an API suits repeatable programmatic work; SaaS suits an ongoing shared workflow.

    Do this: Choose the platform because of where the problem occurs—not because it is fashionable.
  5. 05

    Filter for solo-builder economics

    A promising market can still be a poor solo project if it needs heavy operations, broad integrations, long enterprise sales, or constant moderation.

    Do this: Reject or narrow any direction whose first useful version needs a marketplace, regulated infrastructure, or a large support team.

Evidence checklist

What stronger evidence looks like.

  • The customer and workflow can be described in one clear sentence.
  • The problem happens often enough to create repeated value.
  • Existing alternatives leave a specific, observable weakness.
  • You know where the first 20 potential users can be reached.
  • One builder can deliver the core outcome in weeks rather than years.
  • The product has a plausible reason for customers to pay rather than only try it.

Common mistakes

Avoid evidence that feels useful but changes no decision.

01

Starting with a technology

A new model or framework is an ingredient. The customer outcome must remain the reason the product exists.

02

Copying a large product

A smaller clone inherits the incumbent's competition without gaining a focused reason to switch.

03

Ignoring customer access

An audience you cannot reach makes every validation and acquisition step slower.

Decision rule

Know what would make you continue—or reconsider.

Prioritize ideas with a specific customer, repeated pain, visible workaround, reachable first audience, and a narrow useful outcome. A less glamorous idea with strong access and clear scope is often a better first build than a large market with weak founder access.

Put it into practice

Browse software opportunities by platform, then compare the customer, alternatives, MVP, risks, and first validation step before choosing one.