Method
How we count revenue, and what these numbers cannot tell you
Every benchmark page on this site is built from one dataset: products that publish their revenue through a payment provider. This page is the honest part — where the numbers come from, how medians are computed, and the five questions we cannot answer with them.
Revenue as of 2026-10-30 · sample: 851 products that publish revenue · 435 report a non-zero MRR
Products
851
published and indexable
Revenue data as of
2026-10-30
revenue syncs daily
Aggregates rebuilt
Monthly
last build 2026-10-31
1. What the sample is
The library holds 851 published products that report revenue through a payment provider (Stripe, a merchant of record, or a mobile billing platform). Each product's page shows the numbers it publishes, with the date those numbers were synced.
This is not a census of software businesses. It is the subset that chooses to publish revenue — which is exactly why it is useful and exactly why it is biased.
2. What "verified" means here
- Revenue figures come from the product’s public revenue-verification record, which is connected to its billing provider — not from a screenshot or an interview.
- Where a product does not publish a figure, we either leave it blank or show our model estimate; blanks are never filled with zero.
- Product metadata (category, team size, country, tech stack) comes from the product’s own site and public pages, and moves much slower than revenue.
3. How medians are computed
Medians and percentiles use only products that report a non-zero figure for that field: 435 products for MRR, 646 for 30-day revenue. The denominator is printed next to every table. A product with no reported MRR is excluded from MRR statistics — not counted as zero.
| Field | Used for | Coverage |
|---|---|---|
| MRR | every median and percentile | 435 of 851 |
| Revenue · 30 days | revenue context, case tables | 646 of 851 |
| Revenue · all time | occasional context only | partial |
| Active subscriptions | shown when present, never used for averages | partial |
| Team size | the one-person comparison | 93 of 851 |
| Category | category tables | 616 of 851 |
| Payment provider | the MoR page | 535 provider matches |
Coverage below 100% is stated on the page that uses the field. We do not silently drop rows.
4. What these numbers cannot tell you
| Question | Why we cannot answer |
|---|---|
| Is it profitable? | No cost fields: no model spend, hosting, salaries or ad spend. |
| Does it retain customers? | No churn or cohort data. A high MRR can be a leaky bucket. |
| Is it growing? | Growth is available for 515 products and is noisy month to month; we show it only in context. |
| What does the market do? | Our sample is self-selected. It cannot represent the industry. |
| What should I build? | That is a strategy question. We publish distributions, not recommendations. |
5. Known biases
- Selection: products that publish revenue skew toward small teams, English-speaking markets and AI.
- Survivorship: a product that shut down usually stops publishing, so the bottom of the distribution is understated.
- Category drift: categories are self-assigned and change over time; the "Unclassified" group is large enough to affect category tables.
- Rounding: revenue is stored in whole dollars, and some figures are estimates rather than provider reads.
Corrections
6. Refresh schedule
Revenue syncs daily. The aggregates behind the benchmark pages are rebuilt monthly, and every page shows the date of the data behind it — currently 2026-10-30. When the aggregates change, the page's date changes with them; if only the date changed, the numbers would be lying.
Coverage note: 51.1% of the library reports MRR, which is why the MRR pages say "435 products" and not "851".