How to value an app from public data (the actual arithmetic)

The model is two steps, and both are published

Bright App Data builds an audience base from whatever install, ratings and review evidence a store listing exposes, then multiplies that base by seven bounded factors. Every input is a field you can read yourself on the store page. The output is a range with a confidence label attached.

Every competing valuation tool I have used is a black box: you paste a package ID and a dollar figure appears. That is worthless for a decision worth five or six figures, because you cannot tell which assumption is doing the work. So here is the arithmetic in full. The same model runs behind every entry in /app-reports, and the method notes live at /methodology.

One warning up front, repeated at /disclaimer: this produces an indicative range for screening and prioritisation. It is not a sale price, and the gap between the two is not small.

Step one: the audience base and the square-root curve

The audience estimate is the largest of three proxies: the store's maximum install estimate, ratings count multiplied by 35, or review count multiplied by 20. Highest wins, because each proxy fails differently. Apple publishes no install estimate at all. Google Play publishes a bucket that can be three years out of date. Ratings volume is slow but it is real.

That number then goes through a square root: base = 1,000 + (square root of audience) x 42, clamped between $1,000 and $500,000. The curve matters more than the constant. An audience of 10,000 produces a base of $5,200. An audience of 1,000,000 produces $43,000. A hundred times the users buys you 8.3 times the base.

The compression is deliberate. A 50-million-install free flashlight app is not fifty times more valuable than a one-million-install subscription app, and a linear model would insist that it is. The $500,000 ceiling stops the curve entirely once the audience proxy passes roughly 141 million, because at that scale public signals stop discriminating and any further precision would be theatre.

Step two: the seven multipliers

Each factor is bounded, so no single signal can run away with the number. They compound, which is why a neglected app with a weak listing and a payment complaint cluster lands so far below a maintained one with identical download volume.

The factors are calculated in this order, and the model exposes every one of them in the breakdown attached to each report — so if you disagree with a weighting, you can see exactly which figure to argue with.

Update recency is the harshest factor, by design

Maintenance recency has the widest spread of any multiplier: 1.08x at the top, 0.38x at the bottom. The tiers step down faster than most people expect, because staleness becomes a real risk well before the one-year mark - a listing that has not shipped in seven months is usually not being watched either.

Across the 6,634 apps in Bright App Data's audited set, 20.2% (1,341 apps) have not shipped an update in 180 days, 9.4% (622) in a year, and 4.6% (302) in two years. That last group is surrendering 62% of its public midpoint on one date field.

The obvious criticism of this factor is correct: one shipped build moves it from 0.38x to 1.08x without fixing anything. Read update recency as evidence that an owner is present, not as evidence that the product is good - that is what the other six factors are for.

• 60 days or less: 1.08x
• 61 to 120 days: 1.00x
• 121 to 180 days: 0.90x
• 181 to 365 days: 0.74x
• 1 to 2 years: 0.56x
• Over 2 years: 0.38x
• No date available: 0.72x

A worked example: how a $16,000 midpoint gets built

Take a real-shaped candidate: 500,000 maximum install estimate, 4,200 ratings, 4.1 stars, last updated 300 days ago, released four years ago, offers in-app purchases and carries ads, ASO score 52, two detected issue clusters (one high severity with 9 matching reviews, one medium with 4), and a sampled review set of 40 in which 22 are three stars or lower.

The audience base is 1,000 + (square root of 500,000) x 42 - the root applies to the audience, not to the product - which is 1,000 + 707.1 x 42 = $30,698. Then: x1.097 rating, x0.74 maintenance, x1.03 maturity, x1.28 monetization, x0.906 ASO, x0.72 issue pressure, x0.7525 review risk, giving $16,124 before rounding. The midpoint rounds to $16,000, and because an install estimate, a release date and 100+ ratings all exist, confidence is MEDIUM - so the published range is $9,500 to $27,000.

Now change one field. If that app had shipped a release 45 days ago instead of 300, the maintenance factor becomes 1.08x and the midpoint moves to $24,000. Same product, same reviews, same rating, 50% higher public midpoint. That is the single strongest argument for maintaining a listing you intend to sell.

Confidence, and why the range is deliberately wide

MEDIUM confidence requires three things at once: an install estimate, a known release date, and at least 100 ratings. Miss any one and the report drops to LOW. Most Apple App Store listings are LOW by default, because Apple publishes no install estimate.

MEDIUM spreads the range 0.58x to 1.7x around the midpoint - a top end roughly 2.9 times the bottom. LOW spreads 0.4x to 2.2x, a factor of 5.5. Those spreads look embarrassing next to a competitor's single confident number. They are the honest width of what one store listing can support, and a narrower number would just be a wider error, hidden.

What the model refuses to guess

Everything below is invisible from a store page. The model does not estimate it, infer it, or fill it with an industry average, because a fabricated input that looks like a measurement is worse than a gap.

Public marketplaces commonly quote asking prices as a multiple of monthly profit. A public-signal model cannot produce that figure, because it cannot see profit. Anyone selling you a store-scrape valuation with a profit multiple attached has invented the numerator.

• Revenue, payout history and the split between subscriptions, one-off purchases and ads
• Retention curves, DAU/MAU, and whether installs are paid or organic
• Install-to-purchase conversion rate
• Churn, refund and chargeback rates
• Who legally owns the developer account, the trademark and the source code
• Liabilities: open disputes, licence obligations, unpaid contractors, data-processing commitments
• Source-code condition, dependency rot, test coverage, whether the project still builds
• App Store Connect and Google Play Console analytics of any kind

How to use the range, as a buyer and as a seller

As a buyer, use it to rank candidates before you spend an hour each on them. A screening range that is directionally right across fifty apps is worth more than a precise number on one. When a candidate survives the screen, the private work starts: analytics access, payout statements, a code read and a security pass. That is what /app-audit covers, and it is the only part that produces a number you should wire money against.

As a seller, run the factors backwards and find the one dragging your midpoint. Update recency, ASO foundation and issue pressure are the three you can move without changing your business model. At their extremes those three compound to more than 8x - which says more about how brutal public neglect looks from outside than about any promised sale price.

Of the audited set, 84.1% (5,581 apps) have no preview video and 47.4% (3,143) have never replied to a single review. Both feed the ASO factor. Both are a weekend of work. If you are preparing an app for sale, start there rather than with the price.

Every catalog figure on this page is a snapshot of the audited set taken on 3 August 2026. The catalog grows continuously, so the live totals are higher than the counts quoted here, while the shares move only slowly.