Can you estimate a mobile app's value from public data?

What a public range is actually for

It is a filter, not a price tag. If you are looking at 200 candidate apps, a public-signal range tells you which 20 deserve an hour of your time. That is genuinely valuable and completely different from knowing what an app is worth.

The honest framing is comparative. An app scoring in a higher band than its category peers has better public fundamentals than they do. Whether it is a good purchase depends entirely on numbers you cannot see yet.

The signals that improve an estimate

Every input is a proxy, and each proxy has a known failure mode worth stating out loud.

• Audience proxy — install ranges, ratings count and review count. Fails when an app has huge install counts from a promotion and no active users
• Rating quality — the public average. Fails when years of history mask a recent collapse
• Update recency — the strongest maintenance signal available. Fails for genuinely finished utilities that need no changes
• Listing maturity — how long the app has survived. Fails as evidence of health; survival is not growth
• Monetization signals — in-app purchases, ads, paid status. Shows a business model exists, never whether it performs
• ASO foundation — how much discoverability is being left on the table
• Complaint pressure — recurring clusters that a buyer would inherit as a remediation backlog

The four things that move a real price and are invisible here

Revenue and its quality. A $20,000-a-month app with one enterprise customer and a 30-day contract is worth a fraction of one earning the same from 4,000 consumer subscriptions.

Retention. Two apps with identical install counts and opposite day-30 retention are not comparable businesses, and nothing on the store page distinguishes them.

Ownership and liabilities. Who owns the code, the trademarks, the third-party licences, the outstanding chargebacks, the disputed contractor work. Any of these can make an otherwise healthy app unbuyable.

Code condition. A clean codebase and an abandoned one look identical from the outside. The complaint clusters hint at it, and only a source-code audit answers it.

How to use the range without misleading yourself

Treat a low-confidence range as an ordering signal only. Our model marks confidence as MEDIUM only when an install estimate, a release date and at least 100 ratings all exist; everything else is LOW, and a LOW range spans from 0.4× to 2.2× the midpoint, which is a deliberately wide admission of uncertainty.

Then do the work the range cannot do: ask for console screenshots and export access, verify revenue against a payment processor rather than a dashboard screenshot, check retention cohorts, confirm ownership of every asset, and have someone read the code before money moves.

If a seller resists any of that, the public range is the last honest number you will get — and the resistance itself is the finding.

One note on the comparisons behind a range: any catalog figure quoted next to it — grade distributions, complaint shares, staleness bands — is a snapshot of the audited catalog taken on 3 August 2026. The catalog grows continuously, so live totals run higher than the published counts.