Everyone checks the DAU chart. Almost nobody checks the crash log.
Ask a buyer what they reviewed before acquiring a mobile app business, and you'll hear a confident rundown of MRR, ARPU, day-30 retention, and install trends. Ask what the crash-free session rate looked like over the last two releases, and most go quiet. Nobody put it in the spreadsheet, because nobody asked the seller for it.
That's a real gap, and it's a different kind of gap than on a website. A slow website costs you conversions. An unstable app can cost you store visibility — Google Play and the App Store both use technical stability signals as inputs into how (and whether) an app gets surfaced. Buy an app with a quietly rising crash rate and you're not just inheriting a bug backlog. You're inheriting a ranking problem the seller's screenshots never showed you.
Technical due diligence for apps deserves its own pass, separate from the general codebase checklist you'd run on a website or SaaS product. The financial due diligence tells you what the app earned. The health check tells you whether it keeps earning.
Why stability is a store-visibility problem, not just a UX one
App stores are not neutral pipes. Both platforms track stability as part of ongoing app quality: Android's own vitals documentation flags a crash rate above roughly one percent of daily active users as "bad behavior" that can suppress a listing's visibility and eligibility for featuring. Apple runs equivalent quality signals into App Store Connect's analytics and peer-group benchmarking.
That means a technically unhealthy app isn't just annoying its existing users — it can already be quietly losing the organic discovery that drives new installs, well before revenue shows the damage. By the time a declining-install trend shows up in a screenshot, the underlying stability problem has usually been live for months.
The five numbers to pull before you make an offer
| Metric | What it tells you | Where to find it |
|---|---|---|
| Crash-free sessions % | Overall stability across all users | Play Console, App Store Connect, or a crash-reporting tool (e.g. Crashlytics) |
| Crash-free users % | Whether instability is isolated or widespread | Same dashboards |
| ANR rate (Android only) | Freezes and unresponsive-UI events, distinct from hard crashes | Android vitals in Play Console |
| Rating trend by app version | Whether a specific release introduced a regression | Store reviews sorted by date, cross-referenced with release notes |
| Target SDK / minimum OS version | How far behind current platform requirements the app sits | App store listing page vs. current Android/iOS SDK requirements |
None of these numbers show up in a P&L. All of them show up in your support inbox and your install-to-revenue funnel within a quarter of taking over.
What "good" actually looks like
Benchmarks vary a little by category, but the general shape holds across consumer apps: a crash-free session rate comfortably above 99.5% is a reasonable baseline, 99.9%+ is what teams that actively monitor stability tend to hit, and the most disciplined teams push toward 99.99%. On the flip side, apps that dip below roughly 99.9% crash-free sessions are noticeably more likely to sit under a 3-star average — stability and rating are tightly correlated, because users who hit repeated crashes are far more likely to leave a review than users who don't.
Treat any of these as directional, not a pass/fail gate. A 99.7% app with a clear, fixable cause isn't automatically a bad deal — it's a negotiating input, exactly like a soft month of revenue.
How to actually get this data as a buyer
- 1. Ask for dashboard screenshots dated within the last two weeks, not a historical export from months ago. Crash rates can change fast after a single bad release.
- 2. Request read-only access to Play Console or App Store Connect during due diligence if the deal size justifies it. Sellers who resist this on a mid-size or larger deal are worth a direct conversation about why.
- 3. Sort store reviews by most recent and scan for pattern language — "crashes on launch," "freezes," "won't load" — clustered around a specific date. That date is your regression to ask about.
- 4. Cross-check the app's listed minimum OS requirement against current platform releases. A large gap is a proxy for how long it's been since the codebase was seriously maintained.
- 5. Ask what crash-reporting tool is wired in, and whether anyone actually looks at it. A tool that's installed but unmonitored tells you as much as no tool at all.
- 6. Download the app yourself and use it for fifteen minutes across the core flows. It's the cheapest verification step on this whole list and buyers skip it constantly.
Technical debt hiding behind a clean revenue number
A stable-looking app can still be carrying debt that doesn't show up until you own it. Watch for third-party SDKs — ad networks, payment providers, push-notification services — that haven't been updated in a year or more; platforms periodically force minimum target-SDK bumps, and an app built on stale dependencies can face a scramble (or a store suspension) when that deadline lands. Watch too for a codebase that depends on one person's local setup or personal developer account to ship an update at all. That's not a stability metric, but it's the same category of risk: something invisible in the numbers until the day you need it and it isn't there.
Red flags worth pausing on
| Signal | Why it matters |
|---|---|
| Crash-free sessions trending down over the last 2-3 releases | Active, worsening instability — not a one-time blip |
| 1-star reviews mentioning crashes clustered right after a specific update | Points to a regression that may not be fully fixed yet |
| App targets an OS SDK version several major releases behind current | Real risk of a forced store deadline or removal, plus signals a stale codebase |
| Seller can't produce recent dashboard access or screenshots | You're pricing the one metric you can't verify independently |
| Core SDKs unmaintained for 12+ months with no migration plan | Rebuild cost hiding behind an otherwise clean listing |
None of these should automatically kill a deal on their own. They're pricing and negotiation inputs — a business with real technical debt can still be a fair acquisition at the right price, with a clear post-close plan and budget to fix what's broken.
Where this fits in your due-diligence timeline
Run the fast version — dashboard screenshots plus fifteen minutes using the app — before you submit an LOI. If anything looks off, make read-only dashboard access an explicit condition of deeper diligence, and get any findings reflected in price or a holdback rather than relying on a verbal assurance.
None of this is legal or financial advice — treat it as a starting checklist and loop in a qualified technical or legal professional before you rely on it to structure an offer. But app stability is a claim about the business exactly like revenue is, and it deserves the same scrutiny before you browse deals.FAQ
Do I need to be a developer to run this check?No. Every metric above lives in a dashboard (Play Console, App Store Connect, or a crash-reporting tool) that a non-technical buyer can read once someone grants access or shares a screenshot.
Is a low app rating always a technical problem?Not always — plenty of low ratings are about pricing, UX decisions, or missing features. But when the negative reviews specifically mention crashing, freezing, or the app failing to open, that's a stability signal worth verifying against the dashboards, not just a taste issue.
What if the seller won't share crash dashboard access?That's a reasonable ask to push on for any deal above a small size. If they won't budge, weight the app-store review evidence more heavily and price in the uncertainty rather than taking their word for it.
Should I walk away from a deal with a high crash rate?Not automatically. Treat it like any other diligence finding — price it in, negotiate a holdback, or get a firm remediation commitment before closing, depending on how severe and how recent the instability is.
Crash rate and store-vitals data are some of the cheapest checks in the whole due-diligence process — a dashboard screenshot and fifteen minutes with the app — and skipping them is how buyers end up inheriting a ranking problem they didn't know they'd bought. Add it to your checklist before you check out the Empire Flippers deals or Flippa listings, and set up deal alerts so you have time to run this audit properly instead of rushing it under listing pressure.