Home/Research

Market sizing

Four corrections before our market scanner meant anything

A category's lifetime review count says how big it once was, not whether anyone is arriving now. Here is what we had to fix before the output was usable, including the correction that changed our strategy.

Published 2026-08-30

Stock and flow

A lifetime review count is a stock. It only goes up. It records everyone who ever arrived and said something, including people who have long since left. It is a reasonable measure of how big a category once was. It is not a measure of whether anyone is arriving now.

One category we looked at showed a leader with 3,774 reviews. Against a leader of that size, a competent second entrant looks like a winnable position. The same category produced 10 reviews a month across every app in it. Not the leader — the whole category. It was dead, and the stock figure said the opposite.

The scanner now derives a monthly rate from the dated review feed and treats the lifetime total as background. Everything downstream runs off the rate: ranking, shortlists, the decision to build. The lifetime number is still printed, because it is useful for reading history, but nothing chooses on it.

A search result is not a category

The platform's search is broad-match and ordered by popularity. Neither property is a defect. It is built for a person who will glance at the results that come up first and recognise what they wanted. It is not built to enumerate a market.

A two-word query for a niche tool returned, at the top, a general-purpose utility with over a million ratings. That app is not in the niche. It is in the result set, and once it is there, any average computed over that set — mean rating, mean review count, mean age — is dominated by a member that does not belong. The average is not noisy. It is meaningless.

The fix is a membership rule we control: every word of the query must appear in the app's name or description before it counts as part of the category. It is crude, and it is ours, which are both the point. The boundary is now something we can state, argue about and change, rather than an artefact of somebody else's ranking.

Where we were wrong: complaint volume is not demand

The original design mined negative reviews. The reasoning was that a leader's angriest customers describe the product you should build, and that a category with many angry reviews is a category with unmet demand. The claim about what to build survived contact with the data. The claim about demand did not.

Across all 34 categories we profiled, the dominant complaint is price. Not in most of them. In every single one, at between 25% and 49% of the negative reviews.

That inverts the signal. The people who write the loudest complaints in a category are disproportionately the people who did not want to pay for it. Complaint volume is therefore not a proxy for willingness to pay; it runs closer to the other way. We had been treating complaint volume as demand. It is nearer to the opposite.

What survives is the content of the complaints, not their count. A complaint about a missing feature is a specification. A complaint about price is a statement that the writer was never going to be the customer. The two have to be read apart, and only the first belongs in a case for building anything.

What actually disqualifies a category

One category we measured takes over seventy-six thousand installs a month. By the criterion we started with, that is a large, live market and an obvious candidate. It is still not worth entering, because the platform ships a preinstalled app that does the same job. Free, already present, already the default. No arrival rate changes that.

The size criterion weakened from the other end as well. Once a portfolio is spread across several small apps rather than concentrated in one, the audience each app has to win falls far enough that category size stops being the binding constraint. A category too small to carry a business on its own can still be worth one app among several.

So size — the number the whole scanner was built around — turned out to be nearly the least important thing it reports. The free-canonical check ends an analysis on its own. Size, on its own, ends nothing.

A trap in the public review feed

Worth recording for anyone building the same thing. The public review feed returns a single object rather than a list when a page holds only one review. Code written to walk a list of reviews therefore does not process that review — it raises a type error instead of returning the one item.

The reason this is worse than it looks is where it occurs. It can only occur on categories with almost no reviews. A scanner can run cleanly across every large category, look correct in every log line, and be blind on exactly the small, quiet ones you built it to find.

Handle the single-object case explicitly at the point where the feed is parsed, not further down. Then test it against a category you already know is nearly empty, so the branch has actually executed once before you trust a run.

How to run the same check

Build the category from a relevance filter you control rather than from the platform's ranking, and write the rule down. If you cannot state why a given app is in your set, it is not your set and the averages over it mean nothing.

Derive an arrival rate from dated reviews rather than from totals. Read what the negative reviews are actually about before treating their number as demand, and count price complaints separately from feature complaints — they point in opposite directions.

Check for a preinstalled or free canonical competitor before anything else. It is the only finding that ends the analysis on its own, which makes it the cheapest thing to run first.

Limitations

Review counts are a proxy for downloads with an unknown conversion between them, and that conversion is category-dependent. Rates should be compared across categories rather than read as absolute demand. A category with a higher review rate than another is not reliably a category with more users.

The category count and the complaint percentages come from our own profiling run, and the relevance filter is ours. Someone else's filter would draw slightly different category boundaries, and slightly different numbers would come out the other side.

Questions and answers

How can I tell whether an app category is still alive?

Whether an app category is still alive shows in a monthly rate derived from dated reviews, not in the lifetime review count. The lifetime count is a stock that only goes up. In one category the leader had 3,774 reviews, yet the whole category produced 10 reviews a month, so it was dead. Ranking and build decisions should run off the arrival rate, with the lifetime total kept as background.

Why are averages over app store search results misleading?

Averages over app store search results are misleading because platform search is broad-match and ordered by popularity, so it pulls in apps that do not belong to the niche. A two-word query for a niche tool returned a general-purpose utility with over a million ratings at the top, and that one app dominated every average. A membership rule you control, such as requiring every query word in the name or description, fixes the boundary.

Do negative reviews indicate unmet demand in a software category?

Negative reviews do not reliably indicate unmet demand in a software category. Across 34 profiled categories, price was the dominant complaint in every one, at between 25% and 49% of negative reviews. The loudest complainers are disproportionately people who did not want to pay, so complaint volume runs closer to the opposite of willingness to pay. Complaints about a missing feature remain useful as a specification.

What disqualifies an app category regardless of its size?

A preinstalled or free canonical competitor disqualifies an app category regardless of its size. One measured category took a very large number of installs a month, yet the platform shipped a preinstalled app doing the same job, free and already the default. No arrival rate changes that. Because this check ends an analysis on its own, it is the cheapest thing to run before anything else.

Why might a review scraper fail only on small categories?

A review scraper can fail only on small categories because the public review feed returns a single object rather than a list when a page holds just one review. Code written to walk a list raises a type error instead of processing that review. This happens only on near-empty categories, so the scanner looks clean everywhere else. Handle the single-object case where the feed is parsed, then test it on a category known to be nearly empty.

All research