Why Most Indie Hackers Build the Wrong Thing (And How to Fix It)

There is a particular kind of optimism that comes with being a technical founder. You have the skills to build almost anything. A new idea hits you in the shower, during a commute, or at 2 a.m. while debugging something else entirely. Within a weekend you have a working prototype. Within a month, you are polishing the UI and writing landing page copy. Within three months, you are wondering why nobody is signing up.

This pattern is so common it has become a cliche in indie hacker circles. But the underlying mistake is not a lack of effort, marketing ability, or technical skill. It is a targeting problem. Most solo founders build the wrong thing, and the data backs that up.

The "Scratch Your Own Itch" Trap

The most popular advice given to first-time builders is deceptively simple: scratch your own itch. Find a problem in your own life, build a solution, and assume others share the same frustration. This advice is not entirely wrong. Many successful products started as personal tools. Basecamp began as an internal project management solution. Craigslist started as an email list for friends in San Francisco.

But for every Basecamp, there are thousands of abandoned projects that solved a problem nobody else cared about, or that only a tiny handful of people would ever pay for. The "scratch your own itch" framework fails for three reasons:

• Your itch might not be widespread. Developers are a niche demographic with unusual workflows. What frustrates you may not frustrate the broader market.
• Your tolerance for pain is different. Technical users will cobble together scripts, Zapier automations, and spreadsheets to work around problems. Normal users will not. That means the pain you feel might not be severe enough to justify a paid product.
• You skip validation. When you are building for yourself, there is an implicit assumption that you already understand the market. That assumption replaces the research you should be doing.

The result? You build something technically impressive that nobody asks for. According to CB Insights, 35% of startups fail because of no market need — the most common cause of failure, ahead of running out of cash (29%) and team problems (23%). Not lack of funding. Not competition. Not bad timing. Simply building something the market did not want.

The Three Mistakes That Kill Solo Projects

1. Building Without Research

This is the most lethal mistake, and the most common. A developer gets excited about an idea, starts coding the same day, and treats building as validation. It is not. Shipping a product is not evidence that anyone needs it. According to Failory's analysis, 90% of startups eventually fail, with the majority attributing failure to solving a problem that the market did not prioritize. Many indie hackers spend months perfecting features for a market that does not exist.

The fix is straightforward but uncomfortable: before writing a single line of code, you need to find evidence that real people are already complaining about the problem you want to solve. Not hypothetical future users. Real people, right now, expressing frustration in their own words.

2. Targeting Oversaturated Markets

The opposite failure mode is building in a space that is too crowded. "Yet another todo app" is the running joke, but the same pattern repeats across note-taking tools, habit trackers, link savers, and CRM alternatives. These markets have entrenched players with network effects, brand recognition, and engineering teams of hundreds.

The opportunity for a solo founder does not lie in competing head-to-head with Notion or Todoist. It lies in finding the specific complaints their users have that the incumbents are ignoring. Complaints are signal. They tell you where the existing solutions are falling short, and where a focused alternative could carve out a real niche.

3. Ignoring Signal Strength

Even when founders do research, they often treat all signals equally. A single Reddit post requesting a feature is not the same as a thousand App Store reviews expressing the same frustration. Volume matters. Trend direction matters even more. A complaint that appeared twice last month and ten times this month carries far more opportunity than a complaint that has had stable mentions for two years. The opportunity gap framework provides a structured way to score and rank these signals so you can separate real opportunities from noise.

Most builders never quantify the signals they find. They stumble on a tweet, feel validated, and start building. That is anecdote-driven development, not data-driven development.

Flip the Approach: Start With Pain, Not Product

The most reliable way to build something people will pay for is to invert the process entirely. Instead of starting with a product idea and hoping the market exists, start with documented pain and work backward to a product.

This is what we call signal-first development. The process has four stages:

Find complaints. Go where users are already expressing frustration. App Store reviews, Reddit threads, Twitter rants, support forums, and product Hunt comments are all rich sources of unfiltered pain. Mining App Store reviews for ideas is one of the most effective starting points because the data is public, detailed, and written by frustrated paying customers. You are looking for patterns, not individual anecdotes. When dozens of people independently describe the same problem using similar language, you have found a real gap.

Validate demand. Once you identify a complaint cluster, quantify it. How many people are saying this? Is the volume growing or shrinking? Are these users in a segment that has willingness to pay? A complaint about a free consumer app is different from a complaint about a $200/month B2B tool. The latter signals higher willingness to pay and lower price sensitivity.

Build minimum. Only now do you write code. And "minimum" means it. Your first version should solve the core pain point from the complaint cluster and nothing else. Every extra feature you add at this stage is a bet against your own research.

Iterate on signal. After launch, keep monitoring the same complaint channels. Are users of the original product still frustrated? Has a new pain point emerged that your solution could address? Signal-first development is not a one-time exercise. It is a continuous feedback loop.

The Complaint-to-Cash Pipeline

This approach is not theoretical. There is a direct line from a pattern of negative reviews to a revenue-generating product. Here is how it works in practice.

"I love this app but I cannot believe there is no offline mode. I travel for work and I am constantly losing access to my data."

When a review like this appears once, it is a data point. When it appears hundreds of times across multiple competing apps in the same category, it is a market opportunity. The complaint itself tells you exactly what to build, who will use it, and what their use case looks like. The app reviews are essentially free customer interviews written by people who are already frustrated enough to leave public feedback.

Several well-known products were born from exactly this kind of complaint analysis. Notion gained early traction by addressing complaints about Evernote's bloated interface and confusing organization system. Linear emerged from widespread frustration with Jira's complexity, a pain point visible across thousands of developer forum posts and tweets. Cal.com capitalized on the growing demand for a privacy-first, self-hosted scheduling tool after Calendly users repeatedly voiced concerns about data handling.

In each case, the founders did not invent a new category. They listened to what users of existing products were already asking for, and built a focused alternative that addressed those specific complaints.

Why Velocity Matters More Than Volume

Not all complaint signals are created equal. A gap that has had 500 mentions over the past two years sounds significant, but it might indicate a stable, well-known limitation that the incumbent is deliberately not addressing (perhaps for good strategic reasons). That is a stale signal.

A gap that had 20 mentions last month and 80 mentions this month is far more interesting. That is a rising signal. It suggests something has changed: maybe the incumbent shipped a bad update, maybe a regulatory shift created new needs, or maybe a demographic change is bringing new users into the category who have different expectations.

The velocity of a complaint tells you about timing. And timing, for a solo founder, is everything. You cannot outbuild a large team, but you can outrun them if you spot a rising pain point before it reaches their radar. A spiking complaint, one that is growing at 100% or more month over month, is a window of opportunity that will not stay open forever. Either an incumbent will fix the issue, or another builder will step in.

This is why tracking complaint velocity is at least as important as tracking complaint volume. The best opportunities sit at the intersection of meaningful volume and accelerating growth.

Putting It Into Practice

The signal-first approach sounds straightforward, but doing it manually is time-intensive. Reading hundreds of app reviews, tracking complaint patterns in spreadsheets, and estimating trend velocity by hand is a significant time investment. Most indie hackers will do it once, find a promising lead, and then never return to the process.

That is one reason we built Unbuilt. It continuously scans thousands of App Store reviews across 20 categories, clusters the complaints using AI, scores each gap for opportunity strength, and tracks velocity over time. Instead of spending 20 hours a month manually browsing reviews, you get a ranked list of gaps with demand evidence, competitive context, and a concrete build plan. It is the complaint-to-cash pipeline, automated.

But whether you use a tool or do it by hand, the principle remains the same: start with pain, not product. Let the market tell you what it wants by listening to what it is complaining about. The complaints are already out there, written in plain language, sitting in public databases. The founders who build the right thing are the ones who read them first.

Key Takeaways

1. "Scratch your own itch" is not enough. Your itch may not be shared by a paying market. Always validate with external evidence.
2. No market need kills more startups than anything else. The CB Insights data is clear: build for documented demand, not assumed demand.
3. Complaints are free market research. App reviews, Reddit posts, and social media rants tell you exactly what users want and are not getting.
4. Volume matters, but velocity matters more. A rising complaint signals timing advantage. A stale complaint signals a trap.
5. Build minimum, iterate on signal. Your first version should solve one core pain point. Let ongoing complaint data guide your roadmap.