---
title: "The demand test: how we decide whether an app is worth building"
description: "Before we write a line of code we ask one question of the marketplace: is anyone arriving in this niche now, and is anyone paying? We answer it from public data we scan ourselves, measure flow rather than lifetime totals, read complaints in full, count people rather than seats, and refuse to size a market until we can name the platform mechanism the product depends on."
date: 2026-10-11
lang: en
canonical: https://goingstellar.ro/methods/demand-test-how-we-decide-whether-an-app-is-worth-building/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: Research / Markets
license: CC BY 4.0
alternate_ro: https://goingstellar.ro/ro/metode/testul-de-cerere-cum-decidem-daca-merita-construita-o-aplicatie/
---

# The demand test: how we decide whether an app is worth building

*Before we write a line of code we ask one question of the marketplace: is anyone arriving in this niche now, and is anyone paying? We answer it from public data we scan ourselves, measure flow rather than lifetime totals, read complaints in full, count people rather than seats, and refuse to size a market until we can name the platform mechanism the product depends on.*

> Research · Markets · 2026-10-11 · https://goingstellar.ro/methods/demand-test-how-we-decide-whether-an-app-is-worth-building/

## Key points

- In a category with real paying customers, somebody leaves a trace, usually as reviews or installs; a niche full of apps with no reviews means nobody is paying.
- Lifetime review and install totals are stock that only goes up, so a demand test should measure flow: dated reviews and the days since an app's newest review.
- On the Google Workspace Marketplace the public user count is roughly a count of seats, because a domain-wide install counts every employee, so it says little about how many people chose the app.
- Votes on a public feature-request tracker measure annoyance, not budget; installs the market actually produced are the better veto.
- Before sizing any market on a developer platform, paste the sentence from the platform's own documentation that says the module performs the exact action the product depends on.

## What this is for

Every idea we have looks good on the day we have it. The demand test is the step that sits between an idea and a repository. It is cheap, it runs from the terminal, and its job is to kill ideas before they cost us a month.

The rule underneath it fits in one line: **in a category with real paying customers, somebody leaves a trace.** On most marketplaces the trace is reviews or installs. If apps exist in a niche and nobody reviews or installs them, somebody already built the thing and nobody bought it. *No incumbent is not a green light; it usually means nobody is paying.* That sentence killed our own first-choice idea in an hour: about 39 apps in the niche, zero reviews between them.

This article describes the method. A companion research piece, *Four corrections before our market scanner meant anything*, documents the specific errors we had to fix in the scanner itself; we do not repeat them here.

## One question, six marketplaces

We scan six marketplaces with the same method and a different demand signal on each, chosen because it is the most honest public number that marketplace gives away.

**Shopify App Store:** reviews, because install counts are not public. **WordPress.org plugins:** active installs, a harder signal than reviews. **Atlassian Marketplace:** total installs, from a clean public API. **Google Workspace Marketplace:** the user count on each listing, plus relative search volume from Google Trends. **Google Play:** installs, an exact download count, the rating histogram and whether the app carries ads or in-app purchases. **Apple App Store:** no install figure exists at all, so we work from dated reviews and the in-app purchase prices on the product page, and we state conclusions as bands rather than numbers. The Chrome Web Store is not on the list: it has no usable API and blocks automated reading.

Whatever the marketplace, the scan starts the same way: we define the niche with a relevance rule we control, never with the platform's own search ranking, and we check whether the platform ships its own free app for the job. On the Shopify App Store, 16 of 130 categories were led by the platform's own app when we measured. A free, preinstalled default ends the analysis on its own.

## Flow, not stock

A lifetime review or install count only goes up. It records everyone who ever arrived, including people who left years ago. We call it stock. What matters for a new entrant is flow: how many people are arriving now, and to whom.

So the scanner reads review dates. The sharpest single field is the number of days since an app's newest review. An app whose newest review is four months old is dying, whatever its total says. One app we found had 981 reviews and had been silent for 333 days. Another held 1,459 lifetime reviews, enough to look like a healthy player in its niche, while producing about 2 reviews in 90 days after 63 days of silence. A stock test counts it as a competitor. A flow test shows a vacancy.

## Read the complaints, and read all of them

A leader's 1-2★ reviews are where we look for the product to build. A complaint about a missing feature is a specification written by someone who already pays. That part of the method survived.

Two things changed in how we read them. First, the dominant complaint in every niche we profiled was price, so complaint *volume* shows who did not want to pay. Only feature complaints go into the case for building.

Second, filtering reviews by rating produces a false timeline. In one hunt an agent read only the 1-2★ reviews of a document add-on and concluded it was functionally dead. Read without the filter, its newest review was 4★ and positive, and three of its four reviews from the previous year were positive too. We now read the full review list first and filter afterwards.

We also check the neighbours, not just the leader. In one category all three solver add-ons sat between 2.49★ and 2.67★. When independent teams converge on the same low rating over a decade, the cause is the platform, not the craft. A wounded leader surrounded by equally wounded neighbours is not an opening.

## Count people, not seats; count installs, not votes

On the Google Workspace Marketplace the public user count is roughly the number of seats. When an administrator installs an add-on for a whole domain, every employee is counted. We proved it on our own apps: the developer console showed that one of our most visible listings, **Change Case**, owed almost all of its public number to two organisations, while the people who had installed it themselves were a few dozen. **Alphabetize**, which looked like a minor app, had several times more of those people. We never judge a Workspace app, ours or a competitor's, by the public number again.

Votes on a public feature-request tracker have the same problem in a different form. Two AI research reports recommended Atlassian's public backlog as a better hunting ground than the marketplace. We checked tickets against the installs the market actually produced. A ticket with 617 votes had led to an app with 9 installs; one with 102 votes, to an app with 14. Across the ten ideas worth checking, 4,339 votes had turned into about 440 installs spread over roughly 40 competing apps: about one install per hundred votes. A vote measures annoyance, not budget. The tracker is now a source of hypotheses; installs are the veto.

## Name the module before the market

On developer platforms an idea can fail before demand even matters: the extension point it depends on may not exist. Of the ten Atlassian app ideas proposed by AI research, four rested on a mechanism the platform does not have: a module that intercepts publishing, a schema field holding a comment's previous text, an event for comment edits, and an endpoint that the documentation bars apps from calling. All four fail silently. The manifest deploys, the handler never fires, and you lose a week thinking it is a deployment problem.

So the first gate, before any market analysis, is a sentence pasted from the platform's own developer documentation saying that the module performs the exact action the product depends on: blocks, reads, intercepts. If we cannot paste the sentence, the idea is dead and we do not size its market.

## Where we were wrong

For weeks we ranked our own Workspace apps by the public user count. The ranking was inverted: the app we called the winner had only a few dozen people behind it, and a whole round of hypotheses written to explain its success was explaining a number that did not describe people.

We also capped our own pipeline without saying so. In one round, 15 candidates went into a workflow that only passed the first ten to the gate. Five never reached it, including the two cheapest options we had. The gate is the filter; a silent cap is not. We now log anything a workflow drops.

And we treated AI research as a finder of facts. When we checked the Atlassian proposals, the vote counts were exact in 13 of 13 cases, while status, date or the platform's position was wrong in 4 of 14, and every error ran in the direction that flattered the proposal. Precise where precision is cheap, wrong where being wrong helps.

## Limits

Reviews and installs are proxies for paying customers, with an unknown and category-dependent conversion between them. We compare niches against each other; we do not read the numbers as absolute demand. Our flow estimates on the Shopify App Store come from a page that shows only about ten recent reviews, so for busy apps the rate saturates and two apps that read the same are not necessarily equal. On the Apple App Store there are no install figures at all. And the test says whether a niche is alive, not whether we can win it: that depends on the product, the wedge and the listing, which the scan cannot see.

## Checklist

**1. Mechanism.** Paste the documentation sentence for the module the product needs. No sentence, no idea.

**2. Free default.** Does the platform already ship this for free? If yes, stop.

**3. Membership.** Define the niche with your own relevance rule and write it down.

**4. Flow.** Measure arrivals from dated reviews and days of silence; treat lifetime totals as history.

**5. Complaints.** Read every review first, then separate price complaints from feature complaints. Check the neighbours.

**6. Units.** People, not seats. Installs, not votes. Write the unit next to every number.

**7. Reports.** Verify every name and claim a research report gives you against the marketplace before it influences a decision.

## Questions and answers

### How can I tell whether a software marketplace niche has paying customers?

A niche with paying customers leaves a trace, usually reviews or installs. If several apps exist in a niche and nobody reviews or installs them, somebody already built the product and nobody bought it. The absence of an incumbent is not a green light; it usually means nobody is paying. A demand test should therefore check for that trace before any code is written.

### Why should an app demand test measure flow instead of total reviews?

A lifetime review or install count only goes up and includes people who left years ago, so it describes history rather than current demand. Flow shows how many people are arriving now and to whom. The sharpest single signal is the number of days since an app's newest review: an app with a large total but months of silence is a vacancy, not a strong competitor.

### How should I read negative reviews of a leading app when looking for a product idea?

Negative reviews of a leading app are worth reading because a complaint about a missing feature is a specification written by someone who already pays. Read the full review list first and filter afterwards, since filtering by rating can produce a false timeline. Separate price complaints from feature complaints, and check neighbouring apps: if every competitor has the same low rating, the cause is probably the platform.

### Is the user count on the Google Workspace Marketplace a reliable demand signal?

The user count on the Google Workspace Marketplace is not a reliable count of people. The public figure is roughly the number of seats, because when an administrator installs an add-on for a whole domain, every employee is counted. A listing can owe almost all of its public number to a couple of organisations, so the developer console is a better guide to how many individuals installed an app themselves.

### Are votes on a public feature-request tracker a good sign of demand for an app?

Votes on a public feature-request tracker are a weak sign of demand. When tickets were checked against the installs the resulting apps actually received, heavily voted requests had produced only a handful of installs, roughly one install per hundred votes. A vote measures annoyance, not budget. A tracker is useful as a source of hypotheses, while real installs should decide whether an idea goes ahead.

### What should I check before estimating the market for an app on a developer platform?

Before estimating the market for an app on a developer platform, confirm that the extension point the product depends on actually exists. Paste a sentence from the platform's own developer documentation stating that the module blocks, reads or intercepts exactly what the product needs. Ideas built on a missing mechanism fail silently: the manifest deploys, the handler never fires, and a week disappears. With no sentence, the idea is dropped.

## How to cite

**Cite this as:** Going Stellar (2026). *The demand test: how we decide whether an app is worth building*. GOING STELLAR S.R.L.. https://goingstellar.ro/methods/demand-test-how-we-decide-whether-an-app-is-worth-building/

```bibtex
@misc{goingstellar2026demand,
  title  = {The demand test: how we decide whether an app is worth building},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/methods/demand-test-how-we-decide-whether-an-app-is-worth-building/},
  note   = {2026-10-11}
}
```

Licence. Free to quote with attribution.

## Also available

- This page as HTML: https://goingstellar.ro/methods/demand-test-how-we-decide-whether-an-app-is-worth-building/
- Same article in Romanian: https://goingstellar.ro/ro/metode/testul-de-cerere-cum-decidem-daca-merita-construita-o-aplicatie/