When you inherit an app, you also inherit decisions you did not make. A code audit tells you what you actually have, what is urgent and what can wait. A poor audit gives you a long list of things the reviewer would have done differently. Here is how to get the first kind.
What to give the reviewer
- Read access to the code, ideally with its full history.
- Access to crash reports and analytics, if you have them.
- A list of the accounts you hold, and the ones you do not.
- What the business needs next, because a review with no goal cannot set priorities.
Share credentials through a password manager, or create separate limited accounts. Do not send them in email. Change anything sensitive when the review ends.
What a useful report contains
1. Can it be built and released? This comes first, because everything else depends on it. Does the app build from a clean copy of the repository? Are the signing keys and certificates available? Who holds the store accounts? On Android, check which key is held. Under Play App Signing, Google can reset a lost upload key. If an older app kept its own signing key and it is lost, it cannot be reset, and the app needs a new listing.
2. What could hurt you this month?
- Keys or passwords stored in the code or the app.
- Open database rules or APIs that do not check who is calling.
- Store deadlines, such as a Google Play target API requirement.
- Payment code affected by provider changes.
- Personal data stored or sent carelessly.
- Backups that nobody has tried restoring.
- Libraries with known security flaws, found by a scan rather than by opinion.
3. What is out of date? Libraries, SDKs and OS versions, with how urgent each one is. “Old” alone does not make something urgent.
4. Where is it fragile? What automated tests exist, and do they run? Which parts break when changed, why, and whether you are likely to change them? A messy screen nobody touches can wait. A messy payment flow you change monthly cannot.
5. What does it do today? A short description of the main flows, the back end and connected services. Often nobody has written this down.
6. What do you recommend, in what order, and at about what size? Small, medium or large is enough at this stage, as long as each item has a reason. A made-up example of a good finding: “The database rules allow any signed-in user to read all orders. Risk: high, personal data exposed. Fix: small, about a day. Do this first.”
How to read the recommendation
The answer is usually mixed: fix some parts, refactor others, and rebuild one or two. Ask more questions if:
- The only recommendation is a full rewrite, by the team doing the review.
- The report has no priorities.
- Findings are about taste rather than risk, such as naming or formatting.
- It says nothing good at all. Every app that has real users got something right.
Keep it proportionate
The review should be small compared with the work it might save. If it is priced like a project, ask why. Agree the scope and the output in writing first, including that you keep the report and can take it to another team. That last point is the best protection against a report written to sell you the next job.
After the audit
Do the urgent items first, then make releases boring: one build process, crash reporting, and store requirements met. Our takeover guide covers the order in detail, and our takeover service follows it.