Why Request Counts in Idea Libraries Mislead

There is a number that sells idea databases: "this problem was requested 412 times". It sounds like demand. It is usually an artifact of counting.

We hold 12,631 records. We also ran a near-duplicate pass over the whole set and found 129 matched pairs. Those two numbers together say something important about every idea library you have used, including ours.

Two counts that look the same and are not

The first count is records. A record is one extracted idea from one source post. The second count is distinct source posts. Ours is 10,841.

The gap between 12,631 and 10,841 is not duplication. It is extraction. One long post can describe three different products, and a careful extractor produces three records, because those are three separate requests from one person. That is a feature of the extraction, and it means a record count and a post count answer different questions.

What duplication actually looks like

Duplication is a separate measurement. Two records are duplicates when they describe the same product from different posts, months apart, with different wording and the same core claim.

Our matcher compares titles and problem statements. Title terms weigh twice. A pair is a duplicate when it scores at least 0.40 on weighted term overlap, shares at least two core domain terms, and both records carry a real problem statement. On the current corpus it returns 129 pairs.

That number is a floor, not a rate. The matcher is lexical, so it misses pairs that describe the same product in unrelated words. We do not know its recall, and we will not present the result as "one percent of the library is duplicate" until we can measure it.

Read that honestly. The corpus is not visibly full of repeated junk, and we still cannot honestly say "this idea was requested forty times", because our tooling does not group records into themes with confidence. Anyone quoting a large request count from a library of this size is either using a much more aggressive matcher, and counting near-neighbours as duplicates, or they are counting tags.

The tag trap

Tags are the easiest number to publish and the easiest number to misread.

In our library, the productivity tag appears on 1,976 records, small business on 1,526, automation on 1,483, SaaS on 935 and AI on 618. Those are real counts of records that carry the tag.

They are not counts of people who want the same product. A tag is a topic, not a demand signal. Productivity contains everything from calendar tools to meeting notes to personal task systems. Saying "1,976 people asked for a productivity tool" is technically impressive and analytically empty.

Use tags to choose where to look. Never use them to size a market.

What a count you can trust looks like

A request count is worth quoting only when four things are true. The library shows the underlying records. The grouping rule is published. The count is of distinct posts, not of records. And the same number survives a second pass with a different matcher.

Anything less is a marketing department's version of statistics. You cannot audit it, so you should not plan against it.

A practical test: pick the top entry in a list of frequently requested ideas and ask for its source records. If you get five entries and a lot of confidence, walk away. If you get the posts, the dates, and the wording, you can judge the count yourself.

Do that once. It costs minutes, and it settles whether the rest of the library is worth reading.

Why this matters to you

If you are choosing what to build from a library, a big request count is the most seductive number on the page, and it is the one most likely to be wrong.

Three rules keep you honest.

First, read the underlying entries. Ten entries you have read beat a count of four hundred you have not. If the library does not show you the source record, the count is unpriced marketing.

Second, separate a topic from a job. "Accounting" is a topic. "Reconciling insurance payments against the bank feed every Friday" is a job. Jobs are buildable. Topics are not.

Third, treat a repeated complaint as a hint and a repeated purchase as proof. The only count that predicts revenue is the count of people who paid.

How we use our own numbers

We publish record counts because they are exact and we can reproduce them. We do not publish theme counts as demand, because our current tooling cannot support that claim.

When the grouping improves, the claim will change, and we will say so. A number you cannot reproduce is a sales asset, not evidence.

That is also why we publish the weak number. The 129 matched pairs are not flattering. They are the honest state of our tooling, and a library that hides its own error rate is asking you to trust a count it cannot defend. We would rather show the seam than sell the illusion.

If you want the method that turns a record into a decision, read how to kill a SaaS idea in an afternoon. It uses one record and five questions, and it does not need a count at all.

The broader market argument is in SaaS is not dead, 12,631 founder requests say what changed, and the topic page is build or do not build.

Sources

• SaaS Idea Finder production database, queried 2026-11-05: 12,631 records, 10,841 distinct source post ids, 129 near-duplicate matched pairs.
• The thresholds in the body (0.40 weighted overlap, two shared core terms, title weighted 2x) match the constants in the application source at query date.
• Tag counts are raw record counts by tag, same query date.