Home/Research

Markets · Feature-request backlogs

Do feature-request votes predict app installs? What a public backlog told us

Votes on a platform's public feature-request tracker did not predict installs. Across the ten ideas that passed a first filter, 4,339 votes had turned into about 440 installs spread over about 40 competing apps: roughly one install per hundred votes. The ticket's status carried more signal than its vote count, and the status was the part most often misread.

Published 2026-10-11

Votes are not demand

Votes on a public feature-request tracker do not predict how many people will install an app that solves the request. In our measurement on one software marketplace, 4,339 votes across the ten most promising requests had produced about 440 installs, spread over about 40 competing apps. That is roughly one install per hundred votes, and most of those installs were on free tiers.

A public feature-request tracker is the backlog where a platform's own users file requests and vote for them. It is public, searchable and sorted by votes, which makes it look like a ready-made demand survey. A vote costs the voter one click. An install, and even more a payment, costs them a decision. The two measure different things: a vote records annoyance, an install records a budget.

Why we checked

On 4 September 2026 two AI deep-research reports recommended the same thing: stop scanning the marketplace for gaps and hunt in the platform owner's public backlog instead, where unmet demand is supposedly written down and counted. We took the claim seriously enough to test it at the source rather than adopt or dismiss it.

We checked 14 tickets the reports relied on. For each one we read the ticket itself (status, dates, the platform's own comments) and then looked up the installs of the marketplace apps that already address it. Installs come from the marketplace's public listing data, so the check is reproducible by anyone.

Three tickets, three conversions

The first ticket had 617 votes. An app that does exactly what it asks for exists, has shipped 13 versions in 16 months and carries a 2.5-star rating. It had 9 installs.

The second had 102 votes. The app that answers it was listed precisely in the window when the platform's new API limits were hurting users most, and had shipped 50 versions. It had 14 installs.

The third is the best conversion we found, and it still makes the point. A request with 547 votes, collected over 19 years, is addressed by two competing apps with 149 and 98 installs: about 247 installs in total, most of them on the free tier. Even the outlier turns a vote into an install that pays nothing.

Read together, a request with several hundred votes implies a ceiling of tens of installs, at a price anchored near zero. The vote count told us the problem was real. It told us nothing about whether anyone would pay to have it solved.

The status is the signal, and the status is what gets misread

On a feature-request tracker the status field carries more information than the vote count. We ranked the statuses by what they imply for someone who wants to build an app.

Strong: Won't Fix or Not Being Considered, with the platform on record that it will not build the feature. Only 2 of the 14 tickets were here. Weak: Gathering Interest, which on this tracker is the label for a ticket nobody has triaged yet. 7 of the 14 were here. Poison: Under Consideration, In Progress or Closed, Fixed, where you would be building what the platform owner is already building. 4 of the 10 proposals in the reports rested on tickets like that.

The clearest case was the reports' first recommendation. It was described as a ticket left open and ignored since 2015. The ticket was in fact created in 2013, had been closed as a duplicate in 2024, and the feature had shipped natively in 2025 under another ticket with 2,102 votes, closed as fixed. The recommendation was to build something the platform had already given away.

We enumerated the whole graveyard

The tracker's search works anonymously, so the set of refused requests can be listed completely rather than sampled. Above 200 votes, the complete set of tickets the platform had refused was 38. The Gathering Interest label covered 340 tickets above the same threshold, but because it means untriaged, we treated it as noise.

28 of the 38 died at once for platform reasons: the request needed the native editor's page structure, a change to the data model, or an external integration that an app cannot provide. The remaining 10 went through the installs check. None survived. Those 10 requests had 4,339 votes between them and about 440 installs spread across about 40 competing apps.

The installs check is also the fastest filter we have. Applied to the reports' original proposals it removed 6 of 10 in minutes, on the one question that matters before writing code: does anybody pay?

The page that measures demand also destroys it

On 5 of the 10 surviving requests, the platform itself publishes a free workaround, a knowledge-base article, or direct links to competing apps in the ticket description. On one ticket this is measurable: the platform points 494 voters to a third-party app that has 4 installs. The vote count did not even convert when the platform sent the voters to a solution by hand.

High-vote threads are also where competitors advertise. A vendor with 329 installs posts its own product in the comments of one popular ticket; another app promotes itself in the comments of the 617-vote ticket. Whoever finds the ticket meets an incumbent before their own listing exists.

Someone had already built the most promising of the ten ideas, from exactly the most promising ticket, and named the app after the problem. It had 1 install. Ten vendors working on one of the ideas had 16, 9, 7, 3, 3, 2, 2, 1, 1 and 0 installs. The largest base any exact clone of any of the ten ideas had reached was 16 installs.

An empty niche under a popular request is a wall, not a gap

When a request has many votes and nobody serves it, the tempting reading is that the niche is free. Our data points the other way. A governance vendor with 6,119 installs has sold into the exact area for a decade and never closed a 559-vote request that is 20 years old. Two query-extension vendors with 3,950 and 923 installs both ship custom query functions, and neither offers the ordering that a popular request asks for.

Large, competent vendors sitting next to an unserved request usually means the platform does not allow the thing, or that customers will not pay for it. The useful question is what stops them, not why has nobody noticed.

Where we were wrong

We nearly took the AI reports at face value, because the numbers in them were exact. The vote counts were right in 13 of 13 cases. The status, the date or the platform's own position was wrong in 4 of 14, and every one of those errors ran in the direction that made the proposal look better. The reports were precise where precision was cheap and wrong where being wrong helped the argument.

In the same audit, 4 of 10 proposals depended on a platform mechanism that does not exist: a module, a schema field, an event or an allowed endpoint that the platform's documentation does not provide. None of that shows up in a vote count.

We also kept running the backlog search after its answer was in. The tracker is public and finite, and every vendor on the platform reads the same list. A request old enough and popular enough to look like a signal has usually been everyone's shopping list for years, with the free workaround printed underneath.

How to use a public backlog without being misled

1. Use it for hypotheses only. A tracker tells you which problems users complain about. It does not size a market.

2. Filter by status first. Keep the requests the platform has refused on the record. Drop untriaged ones, and drop anything under consideration, in progress or fixed.

3. Check the platform's own text. Read the ticket description for workarounds, knowledge-base links and links to competitors.

4. Use installs as the veto. Before any code, look up the installs of every app that already addresses the request. If exact clones sit at single-digit installs, the request is not a market.

5. Ask what stops the incumbents. A big vendor next to an unserved request is evidence of a wall.

Limitations

This is one platform's tracker and one marketplace, measured on 4 September 2026. The conversion figure is an aggregate over about 40 apps; individual requests ranged from single-digit installs to the two-app outlier above. Votes accumulate over years while installs are a snapshot, so the ratio compares different time windows.

Public install counts include free tiers and trials, so they overstate paying customers rather than understate them, which makes our conclusion conservative. We only enumerated requests above 200 votes. A different threshold, or a tracker on another platform, could produce a different ratio, though we would expect the direction to hold.

Questions and answers

Do votes on a feature-request tracker predict demand for an app?

Votes on a feature-request tracker do not reliably predict demand for an app. In one measurement, ten popular requests with 4,339 votes between them had produced about 440 installs across about 40 competing apps, roughly one install per hundred votes, mostly on free tiers. A vote costs one click and records annoyance. An install or a payment records a decision, which is the signal that matters before building.

Which feature-request status is a good sign for building an app?

The best status for building an app is one where the platform has refused the request on the record, such as Won't Fix or Not Being Considered. Gathering Interest often just means the ticket was never triaged. Under Consideration, In Progress or Closed as Fixed are dangerous, because the platform owner is building or has built the feature. In one audit, 4 of 10 proposals rested on such tickets.

Why is an unserved popular feature request not a market gap?

An unserved popular feature request is often a sign of a wall rather than a gap. In one measurement, a vendor with 6,119 installs had worked in the same area for a decade without solving a 559-vote request. When capable incumbents sit next to an unserved request, the platform usually blocks the feature or customers will not pay. The right question is what stops the incumbents.

How should I use a public feature-request backlog when looking for app ideas?

A public feature-request backlog is best used as a source of hypotheses. Filter the requests to those the platform has refused, read each ticket description for free workarounds and links to competitors, then check the installs of apps that already address the request. If exact clones have single-digit installs, the request is not a market, however many votes it has.

Can AI deep-research reports be trusted on marketplace demand?

AI deep-research reports should be checked at the source before they drive a build decision. In one audit the vote counts in two reports were exact in 13 of 13 cases, but the ticket status, date or platform position was wrong in 4 of 14, and every error favoured the proposal. Exact numbers made the reports look reliable where it mattered least.

All research