What should I build? How to find startup ideas from real problems

The most common question from a first-time founder in 2026 is some version of: "I want to build something. What should I build?" The honest answer is that "what to build" is the wrong question. The right question is: "where do I look for problems people are already paying to solve, badly?"

Paul Graham made the same point in 2012: "The way to get startup ideas is not to try to think of startup ideas" (How to Get Startup Ideas, November 2012). This essay is the working method behind our directory of 100 scored startup problems. You can run it in a weekend and end up with three or four strong candidates of your own.

Step 1: pick a habitat, not a topic

Most "what to build" guides tell you to pick a topic you care about. That advice fails because it pushes you toward your own assumptions. Pick a habitat instead: a place online where a specific group of people complain in long, specific paragraphs about specific problems.

A good habitat has three properties:

• The complaints are concrete. "I hate my landlord" is useless. "My landlord auto-charged me $50/month for renters insurance I already had" is gold.
• The complaints repeat. One angry post is anecdote. Forty similar posts in twelve months is a pattern.
• The complainers can afford to pay something. Subreddits for low-income high-school students are full of pain. They are not a market.

Where to find problems to solve

Habitats worth reading: r/personalfinance, r/smallbusiness, r/Frugal, r/ecommerce, r/sales, r/k12sysadmin, r/Teachers, r/legaladvice, r/Plumbing, r/medicine, r/talesfromtechsupport, IndieHackers, Hacker News "Ask HN: what do you wish existed", one-star App Store reviews of category leaders, and review sites such as G2, Capterra and Trustpilot for legacy software.

Two quieter sources often beat forums. Job postings that describe a person doing a task by hand ("reconcile supplier confirmations against POs") point at work someone is already paying a salary for. Regulator notices and new rules point at deadlines a small business cannot ignore. Both show a buyer, not just a complainer.

Step 2: read sideways, not down

The trap when you sit on a subreddit is to read top-of-feed: the trending posts. That is recency bias. The signal lives in the long tail of posts with five comments and zero upvotes, where someone described a real problem precisely enough that no one bothered to react.

For each habitat, sort by "new" and read fifty posts. Then sort by "top, all time" and read another fifty. The overlap is your candidate set. Write down each complaint in the person's own words, with the link. Aim for 8 to 12 candidates.

Step 3: score on four axes

Every candidate problem gets four numbers, each 1 to 10. We weight them into an opportunity score: severity 30%, feasibility 25%, market signal 25%, competition gap 20%. It is the same rubric explained on our methodology page.

1. Problem severity. How much pain does this cause, in hours or dollars, to the affected person? A weekly 30-minute frustration is a 4. A monthly $300 surprise charge is a 7. A six-month lost-deal cycle for a small business is a 9.
2. AI feasibility. How well-suited is current AI to solving this? Categorising bank transactions is a 9. Diagnosing a rare disease from a photo is a 4.
3. Market signal. How many people credibly experience this? "Tech founders" is a 5. "Anyone with a credit card" is a 9. Read the platform numbers, not just the post count.
4. Competition gap. How wide is the space between the leading existing solution and what the user actually wants? Big gap is good. If a category leader already does 80% of what users want, the gap is a 3. Our tools page lists what already exists for each problem, and the gap.

Want a quick second opinion on a candidate? Build or Skip takes a one-line problem and checks how many Show HN launches already exist, how much Ask HN demand there was in the last 12 months, and whether it matches a problem in our catalogue. It is a prototype and a first filter, not a substitute for Step 4.

Step 4: stress-test with the "five names" rule

Before you commit to building anything, find five real people who have this problem. Not five hypothetical buyers. Five named people with email addresses, who agree to talk to you for fifteen minutes.

If you cannot find five people in two weeks, the habitat was noisier than the market is real. Drop the problem and pick the next one on your scored list.

If you find five and the first three calls confirm the problem in the exact words you read online, the problem is real. The next two calls should be about willingness to pay, not "is this a problem." Ask what they do today and what it costs them; a workaround they already pay for is the strongest signal you will get. Our guide to validating a startup idea before you code turns this into a weekend plan.

Step 5: pick the wedge, not the platform

A common mistake among first-time founders is to pitch the eventual platform. "An AI ops layer for small healthcare practices." That is the destination. The wedge is one specific painful workflow.

For each scored problem, ask: what is the smallest, sharpest thing I can build in eight weeks that takes one painful workflow from five hours to fifteen minutes? That is the wedge. The platform is what you build after the wedge has paying customers.

Should you solve your own problem?

Paul Graham's essay recommends problems you have yourself, and it is good advice for a reason: you understand them, and you will notice when a fix works. The risk is stopping there. Treat your own problem as one lead on the list, not as proof. Look for the same complaint in strangers' words, score it like any other, and put it through the five-names test. If it survives, you have the best of both: insight and evidence.

The three traps to avoid

Building from your own life alone. Your own problems are rarely unique, but they are often shared only with you and your three closest friends. Three friends is not a market.

Conflating "interesting" with "valuable." AI for art curation is interesting. AI for sales-tax tracking is valuable. The interesting problems are crowded. The valuable problems are not.

Mistaking platform shifts for new markets. "ChatGPT exists, therefore X needs to be rebuilt" is a thesis, not a problem. The problem still has to be the problem first. The new platform just changes the feasibility score.

Questions founders ask

Where can I find problems to solve for a startup?

Look where a specific group of people complains in long, concrete paragraphs: niche subreddits, IndieHackers, Ask HN threads, one-star app store reviews of category leaders, software review sites, job postings that describe manual work, and support forums. Read the quiet posts, not just the trending ones.

Should I build a startup around my own problem?

Your own problem is a good lead, because you understand it, but it is not proof of a market. Treat it as one candidate, look for the same complaint in other people's words, and find five named people who have it before you build.

How many startup ideas should I compare before choosing one?

Collect 8 to 12 concrete problems from one habitat, score each on severity, AI feasibility, market signal and competition gap, and carry the top two to four into customer conversations. Choosing from a scored shortlist beats falling for the first idea.

Found a problem we have not listed? Submit a problem in your own words and we will check what already exists and score it on the same four axes.