Sample: what an app health check report looks like

This is a sample. The headings and the kind of content under each are real: they are what our health check reports contain. The app, the names and every figure are placeholders, shown in square brackets, so you can see the shape without us inventing a client. A real report for a typical app runs to a few pages.

1. Summary

One paragraph, written last, read first. What the app is, what state it is in, and the three things to do first.

[App name] is a [Flutter] app for [iOS and Android] with a [server technology] backend, built by [previous developer] and last updated [date]. It works for most users today but cannot currently be updated in either store, because the signing key is missing and the Android target version is below Google's current requirement. The backend has no backups. Priorities: recover or reset the signing key, bring the target version up to date, and set up backups. Everything else can wait for those three.

2. What exists

A plain inventory, so there is no argument later about what was handed over.

3. Risks, in order

Each risk has a severity, what happens if it is left, and what fixing it involves. Severity is one of three words: urgent (customers or data are affected now, or will be on a known date), soon (will become urgent within months), later (worth doing, no deadline).

• Urgent: no backend backups. A disk failure or a mistake loses all bookings since launch. Fix: scheduled backups to separate storage, and a tested restore. [Effort estimate.]
• Urgent: store updates blocked. Android target version is [X]; Google requires [Y] for updates. The next bug fix cannot ship until this is raised. Fix: raise the target, resolve the resulting changes, test on [list of versions]. [Effort estimate.]
• Soon: signing certificate expires [date]. After that, no iOS builds can be submitted until it is renewed from the Apple account, which is not yet in the company's name.
• Soon: dependencies out of date. [N] libraries are more than two years behind, including [one with a published security advisory]. Fix: staged upgrade.
• Later: secrets in the code. [Service] keys are written into the source. Anyone with the repository has them. Fix: move to configuration, rotate the keys.

4. Code and architecture

Written for a developer, with a plain summary at the top for the owner. Covers: how the app is structured, whether it can be built from a clean machine (we try), test coverage, the state of the backend and database, and anything that would make changes slow or risky. It says clearly whether the code is worth keeping. In most cases it is; a recommendation to rewrite comes with the evidence for it.

5. Crashes and performance

What the crash reporting shows, if any exists: crash rate, the top crashes, which devices and versions. If no crash reporting is set up, that is noted as a risk and the first thing we add.

6. Accounts and ownership

A list of every account that must be transferred or re-registered into the company's name, who holds it today, and the steps for each. This section becomes the checklist for the next stage of work.

7. Recommended plan

Three stages, each priced separately, so you can stop after any of them:

1. Stabilise. The urgent items in section 3, in order.
2. Make it safe to change. Ownership transfers, backups, crash reporting, a repeatable release process, tests around the risky parts, a short written description of how the app works.
3. Improve. The changes you have been waiting to make, now that making them is safe.

8. What we need from you

The short list of access and decisions needed to start stage one.

---

That is the whole shape. If you are reading a health check from anyone, including us, and it does not say what exists, what is at risk and what to do first, in that order, ask for the missing part.

Our own health check is the Existing App Audit and Recovery package. Its starting price is on the pricing page.