How to pick one app idea from a shortlist

Pick the idea with the strongest evidence, not the one you're most excited about. Score each idea on four things: who's complaining, how often the complaint comes back, whether people already spend money or time on a workaround, and whether you can actually reach them. The idea that wins on evidence and reachability is the one you test first.

Most solo builders don't have a shortage of ideas. They have a notes file with five half-good ones and a habit of switching whenever one gets hard. This post is about making the call and sticking with it long enough to learn something.

It sits next to how to find app ideas people actually need and how to research your app audience. Those cover spotting problems and naming who has them. This one is about choosing between ideas you've already found.

Written for solo app builders, not agencies.

Why shouldn't I just pick the idea I like most?

Because liking an idea tells you about you, not about the market. Excitement matters, since you'll need it to keep going, but it's a tiebreaker, not a first filter.

The ideas that feel best in your head are often the ones with the least friction: no one has said no yet, because no one has been asked. An idea with messy, specific complaints attached to it usually feels less shiny and is much easier to test.

So keep enthusiasm out of the first pass. Bring it back at the end if two ideas are close.

Who exactly is complaining about each idea?

Write down, for each idea, the person who has the problem. Not "small businesses" or "creators." Something like "freelance bookkeepers who chase clients for receipts every month" or "Shopify store owners handling returns by email."

If you can't name them, the idea isn't ready to compare. Go back to research first.

Then check the evidence behind the name:

• Are these firsthand complaints ("I spend my Sunday doing this") or secondhand guesses ("people probably hate this")?
• Do the complaints come from one kind of person, or from a loose crowd that only shares a keyword?
• Would you recognize this person if they posted in a thread tomorrow?

A narrow, recognizable person beats a big, blurry market. You can't run an experiment on a blur.

How often does the problem come back?

A problem people hit once a year is a weak base for a small app. A problem they hit every week, or every time a certain thing happens, gives you repeat pain and repeat reasons to open your product.

Look at your own notes and the threads you saved:

• Do the complaints show up across different dates, or did they all come from one viral post?
• Is the pain tied to a recurring moment (month-end, every new client, every shipment)?
• Do people describe it as "again" or "every time"?

If the evidence is one loud thread, treat it as a lead, not a signal. The build signal bar applies here too: dated, repeated, firsthand.

Are they already paying for a workaround?

This is the strongest single clue you'll get before you build. People who already spend money, time, or effort patching a problem have shown you it matters to them.

Workarounds look like:

• A spreadsheet or template they maintain by hand
• A paid tool they use for something it wasn't designed for
• A freelancer or VA they pay to handle the chore
• A Zapier chain, a script, or a long checklist they keep tweaking
• Hours each week they openly resent

No workaround usually means one of two things: the problem isn't painful enough to act on, or it's so new nobody's tried yet. The first is common. Be honest about which one you're looking at.

Can you actually reach these people?

An idea you can't get in front of is an idea you can't test. Reachability is the filter solo builders skip most, and it's the one that decides whether your first experiment happens at all.

For each idea, ask:

• Where do these people already talk? A specific subreddit, a niche Discord, X replies under certain accounts, review pages for a tool they use?
• Can you show up there as a helpful person without breaking community rules?
• Do you already have any access: you're in the community, you've done the job, you know a few people who do?

If the honest answer is "I'd have to buy ads to find them," that idea should drop down your list for now. Being able to show up in threads worth replying to is a real advantage when you're one person with limited hours.

How do I compare the ideas side by side?

Write a short card for each idea. Four lines, one per question, with a plain note instead of a score you'll fudge later:

• Idea A. Who: freelance bookkeepers, firsthand. How often: every month-end, across many dates. Workaround: a paid VA plus a shared spreadsheet. Reachable: yes, I'm already in their subreddit.
• Idea B. Who: "founders," vague. How often: one big thread. Workaround: none I've seen. Reachable: not sure.

Then apply a few plain rules:

1. Drop any idea where "who" is blank. It isn't comparable yet.
2. Weight workaround and reachability heaviest. They tell you whether someone will care and whether you can find out.
3. Break ties with fit. Pick the one you understand best or would enjoy working on for months.
4. Pick one. Park the rest in a dated note so you can come back with fresh evidence later.

The cards are there to make your reasoning visible. If you catch yourself arguing with them, write down why. Sometimes you know something the notes don't. Often you're just attached.

What do I do once I've picked?

Commit to a short window and one test. Don't start building the whole product, and don't reopen the shortlist the first quiet day.

Turn the winning idea into a one-line promise in your audience's words, then design one first marketing experiment with a clear pass and fail line. If it fails, you go back to the shortlist with real data instead of a hunch. That's the point of picking carefully: a no teaches you something.

Next step

If your shortlist is thin or every idea is missing evidence, start from something concrete. earlyaf. gives solo builders a free reviewed daily idea, plus audience research that shows who has the problem and where they talk, and guidance for turning that into a first experiment. Reply Radar finds and scores Reddit and X posts that might be worth answering and puts them in a queue. You read them and write every reply yourself.

Soft next step: Find ideas for my audience, then run your shortlist through the four questions above before you write code.

FAQ

How many ideas should be on my shortlist?

Few enough that you can gather evidence for each one in a sitting or two. If the list is long, cut anything where you can't name who has the problem. That usually shrinks it fast.

What if two ideas tie on evidence?

Pick the one you can reach this week. If that ties too, pick the one you'd rather work on. Then stop comparing and start testing.

Should I validate every idea before choosing?

No. Compare on the evidence you already have, pick one, and test that. Validating everything in parallel splits your time and usually ends with no clear answer on any of them.

Is a crowded market a reason to drop an idea?

Not on its own. Competitors can be proof that people pay. What matters is whether there's a specific slice of people the current options serve badly, and whether you can reach them.