App due diligence checklist: what to check before buying

Run the public pass first: it is free and it kills most deals

A store listing will not tell you whether an app is profitable. It will tell you, in about ten minutes, whether it is maintained, whether its users are repeatedly hitting the same wall, and whether anyone is answering them. That is enough to reject most candidates before you sign an NDA.

Of the 6,634 apps Bright App Data has audited, 62.3% (4,131) carry at least one recurring complaint cluster - 13,904 clusters in total, 12.5% of them high severity. That is not a fringe of broken apps. It is the majority condition of the store, and it means an acquisition target with a clean review profile is the exception worth paying for.

The public pass runs on every entry in /app-reports. Where it matters is what it hands you: a shortlist and a list of specific questions to put to the seller.

The checklist: public evidence versus private confirmation

Each row is one check. The middle column is what you can establish yourself, for free, before contact. The right column is what you must demand access to - and if a seller refuses any single row on the right, that refusal is the finding.

Red flags, ranked by how often they actually appear

These are the complaint clusters Bright App Data detects most often, as a share of all 6,634 audited apps. The ranking is useful because it tells you which findings are ordinary and which are genuinely unusual.

The top two are a tie, not a podium: payment at 28.6% and device compatibility at 28.4% are separated by fifteen apps, so read them as one shared first place. They fail for opposite reasons, though. Device compatibility is what happens when an app stops shipping - the OS moves, the device population turns over, and the listing does not. It reads as an engineering problem and it is really a staffing one. Payment is usually entitlement plumbing that was never finished, and it is the one that arrives with a refund queue attached to it.

Judge severity by recency and version, not by volume. Fifty crash complaints spread over three years of an app that has since shipped four releases is history. Six crash complaints in the last two weeks against the current version is a live defect, and it is the one that will land in your lap on day one.

• Payment problems - 28.6% of audited apps
• Device compatibility - 28.4%
• UI and usability - 25.4%
• Subscription friction - 21.8%
• Login and account recovery - 17.2%
• Customer support - 15.2%
• Crashes - 10.3%

The transfer mechanics people forget until closing week

Most failed app deals I have seen do not fail on price. They fail because an asset turned out not to be transferable, and that is discovered late because nobody asked early.

Ask for all of it in writing during the first serious call. A seller who has to go and find out who owns the Firebase project is telling you how the handover will go.

• Store account transfer: both Apple and Google have their own transfer process and eligibility rules - confirm the app qualifies before agreeing terms
• App signing keys and the upload certificate, which are not always in the seller's possession if an agency shipped the app
• The backend: hosting, database, and whether it is a shared instance serving the seller's other apps
• Push notification certificates and keys
• Third-party accounts: analytics, crash reporting, subscription infrastructure, ad networks - each with its own billing relationship
• Domain names, the privacy policy URL and the support email that the listing points at
• Any SDK with a commercial licence tied to a company, not to the app

Reading the rating, properly

The rating distribution across the audited set: 402 apps below 3.0, 1,315 between 3.0 and 3.9, 1,993 between 4.0 and 4.4, and 2,064 at 4.5 or above. Anything below 4.0 sits in the bottom third of the population.

A low rating is not automatically a reason to walk. A 3.4-star app whose complaints cluster on one fixable thing - a broken login flow, a payment provider that fails in three countries - can be a better buy than a 4.4-star app with flat installs and no complaint pattern to fix, because the second one gives you nothing to improve. What you are pricing is the gap between the current state and the achievable state.

What should make you walk: complaints that cluster on the business model rather than the build. Refund demands, accusations of dark-pattern subscriptions, and store-policy language in reviews are inherited liabilities, not a backlog.

Turning findings into a number

Sort everything the checklist produces into three buckets, because they affect price in completely different ways. Liabilities you inherit - open disputes, a subscription flow that generates refund demands, an SDK licence that does not transfer - come off the price or end the deal. There is no version of those you fix cheaply.

Remediation work is different: it is quotable. A crash cluster on one device family, a broken login on a specific OS version, a listing with no video and no localisation - price each as engineering hours at whatever your build costs, and subtract that. Bright App Data's own public model already prices some of this crudely: a two-year-stale app carries a 0.38x maintenance factor against 1.08x for a maintained one. That asymmetry is your opening argument, and the seller's obvious counter is that the fix is one release. Both of you are right, which is roughly where a fair price sits.

The third bucket is upside - the growth you think you can produce after the handover. Never pay for it. It is the part of the deal that depends entirely on you, and paying the seller for your own future work is the most common way buyers overpay for an app.

If you are selling, run this checklist against yourself first

Every gap a buyer finds becomes a discount. The cheapest ones to close before listing are documentary: get the payout statements exported, get the console analytics screenshotted, get ownership of the third-party accounts consolidated into one address you control.

Then close the public gaps, because they are what sets the buyer's opening anchor. Ship a maintenance release. Reply to the complaint threads that are still open. Fix the listing - 84.1% of audited apps have no preview video, so the bar is low. A private ASO and technical audit at /app-audit exists precisely to produce that punch list, and /contact is the fastest route to one.

Three honest limits, also stated at /disclaimer and /methodology. First, no public dataset can tell you what an app will sell for; it can only tell you what a buyer will ask about. Second, our audited numbers describe the apps Bright App Data has crawled, which skews towards small and mid-sized listings rather than the top charts - they are a useful baseline, not a census of the store. Third, every figure here is a snapshot of the audited catalog taken on 3 August 2026, and the catalog grows continuously, so the live totals are higher than the counts printed above.