How to validate an app idea with your competitor's reviews

Chart data tells you an app is winning. It cannot tell you what is wrong with it, and what is wrong with it is the only part you can actually build against. That is what the reviews are for, and reading them properly is a counting exercise, not a browsing one.

1. Read the incumbents, not the market

Pick the apps that are actually charting in the category and storefront you care about. Top grossing tells you who is being paid; the biggest recent climbers tell you whose lane is being contested right now. Both are worth reading, and neither is a random sample of the App Store.

Skip the megacaps. An app with millions of current-version ratings has a complaint volume that will drown everything else in your sample and an engineering budget you are not going to out-build.

2. Read the RECENT negatives, and only those

Lifetime average rating is nearly useless here: it is dominated by history. What you want is the recent one and two star reviews, because those are complaints about the app as it ships today. Apple's review feed is ordered so you can get them.

A useful sample is around 200 recent reviews per app per storefront. Fewer and one angry week distorts everything.

3. Cluster by root cause, then count the cluster

"Crashes on launch since the update" and "won't open anymore" are one complaint, not two. Group by what is actually broken, then count each group exactly.

The count is the entire point. A counted complaint is a specification you can build against, and an uncounted one is a feeling you had while reading. Our own gate is at least 25 recent negative reviews on one root cause, and at least 25% of the negative sample. An app that clears neither is not an opportunity, whatever the reviews sound like.

4. Sort the clusters by whether you can fix them

Not all complaints are buildable. In practice they fall into three groups, and only one of them is yours:

• Pricing and packaging. A paywall that lands after the work is done, a trial that promised a reminder and sent none, an export that turns out to be a tier. These are the most buildable openings on the App Store, because fixing them is a product decision rather than an engineering programme. The strongest ideas in our own runs are overwhelmingly this shape.
• Missing capability. Buildable, but now you are competing on features with a company that has more engineers than you.
• Scale, trust and content licensing. Not buildable by one person. A complaint about a catalogue being incomplete is a licensing problem wearing a product costume.

5. Quote it verbatim, or it is not evidence

Keep the actual sentences, with counts attached. The moment a complaint is paraphrased it becomes something you decided rather than something you found, and the difference matters most at exactly the moment you are about to spend a month building.

This is also the check that catches a fabricated opportunity. If a cluster cannot produce real quotes on demand, it was invented somewhere between reading and writing. Every idea in our published run carries its own counts and quotes for that reason, and picking the category first is what keeps this step from producing a great idea in a market you cannot enter.

What reviews will not tell you

Reviews are a self-selected sample of angry people, which is exactly why they are useful for finding defects and useless for sizing demand. Never read complaint volume as market size: a big app generates more complaints than a good idea generates customers.