Competitor Research for Indie Hackers

You open six tabs of competitor sites, skim the pricing pages, and close them with no clear idea what you learned. A pricing page is a marketing artifact. It tells you what a company wants you to think about itself, not what its users are stuck on.

What competitor research is actually for

Good competitor research answers three questions: what people already use, what those people complain about, and what nobody is doing yet. None of those live on a landing page. They live in threads, reviews, and issue trackers.

The goal is not to copy a product. It is to find the seam. Every established tool serves some group of users badly, because serving everyone well is how you end up serving no one well.

Read the complaints, not the landing page

Start where the unhappy users are and note what keeps coming up.

• Abandoned tools. Search for “switched from” and “moved away from” and read why.
• Pricing complaints. Not “too expensive” in general, but “fine until you hit the seat limit”.
• Missing features. The phrase “does anyone know a tool that” usually ends in the feature someone actually needs.
• Support friction. Slow replies, thin docs, and forced upgrades are workarounds in disguise.
• Export and lock-in. People asking how to get their data out are people already shopping.

Write down every complaint that appears more than once. A complaint you see from several users across several threads is a gap you can name.

Reviews on marketplaces and comparison pages help too, but they are shaped by the platform and often written right after a purchase. Threads that happen weeks later, once the novelty has worn off, tend to be blunter. Weight the late complaints more than the launch-day ones.

A repeatable competitor pass

Run this once per competitor and keep the notes in one file.

1. List the two or three tools your audience names most often.
2. For each one, search its name plus “frustrating”, “alternative”, and “switched from”.
3. Read the threads and copy the exact complaint sentences with their links.
4. Sort the complaints into what the tool does too much of, and what it does not do at all.
5. Note the audience the tool seems to have left behind, such as solo users after it added team plans.
6. Write one sentence per gap: who is hurting, and what they do about it today.

Step five is where the opportunity usually hides. When a tool grows up, it moves toward bigger customers, and the small ones it started with get left with features built for someone else.

Keeping what you find

A competitor note is only useful if you can read it months later. Keep it short and factual:

• The tool and the link.
• The exact complaint, in the user’s words.
• How many threads you saw the same complaint in.
• The workaround the user chose instead.

Do that for two or three tools and you have a map of the space that is more honest than any pricing page. It also gives you the vocabulary for your own positioning, because you can describe the gap in the words your future users already use.

Revisit the file before each build decision. Complaints age, and a gap that was real last year may have been closed by a release since. One line of dated notes saves you from rebuilding something a large tool already shipped.

Turning complaints into a position

Once your notes hold three or four repeated complaints, you have the raw material for a position. Do not turn it into a feature list. Turn it into a sentence that names the user and the gap: for solo bookkeepers who outgrew a spreadsheet but do not want a team plan.

That sentence does two jobs. It tells you what to build first, and it tells you who to talk to. The complaints you collected already carry the words those people use, so you can describe their problem back to them without guessing.

Keep the position narrow at the start. If two gaps both look real, pick the one you can reach, not the one that sounds bigger. A small gap with a reachable buyer beats a large gap with nobody to call.

FAQ

Should I look at competitors before or after finding a problem?

Before you commit to a problem, not before you have one. Start with the pain, then look at who claims to solve it and who those users complain about. If you start from competitors, you tend to build a slightly different version of something that already exists.

How many competitors do I need to review?

Two or three that your audience names often. More than that and you spend the week reading marketing copy. Fewer and you may mistake one company’s choices for a market norm.

What if the market is crowded?

Crowded is normal, and it is usually proof that people pay for the job. The question is not whether competitors exist but where their users are unhappy. A crowded market with a well-known underserved segment is a better place to start than an empty one.

Can’t I just ask my network about competitors?

You can, but a handful of friendly opinions will not show you the pattern. Public threads show you the same complaint from people who have never heard of you and have no reason to be polite, which is exactly the evidence you want.

You can do the pass above thread by thread, and it works. It is just slow, because each tool needs several searches and a careful read. MicroSaas Research gathers those discussions from a public Reddit archive plus Hacker News, Stack Overflow and GitHub, groups the complaints by problem, and returns a report with quotes checked against the source text. If you want to sharpen the searches first, read Reddit search operators that surface complaints and why subreddits beat surveys.