What a Code Audit of an Inherited App Actually Covers

An audit is what you buy when the decision is bigger than the question. Someone wants to sell you a company, or finish a project, or take over maintenance, and the honest answer to whether that is wise is sitting in a repository nobody independent has read.

It is deliberately short work. A few days of reading and testing, ending in something a non-technical owner can act on. What follows is what those days are spent on.

What an audit is, and what it is not

An audit is not a code review. A review improves a change someone is about to make. An audit answers a commercial question: can this be built on, what does it hide, and what would the first six months cost.

That distinction matters because it decides what gets ignored. Inconsistent naming, dated libraries and unfashionable patterns are not findings. They are opinions, and a report full of them buries the two or three things that actually change your decision. An auditor who hands you forty issues of equal weight has not done the hard part, which is ranking them.

Whether anyone can reach data they should not

This section is answered by doing, not reading. Two accounts are created, and one tries to reach the other's records by changing an identifier in a request. If that works, nothing else in the report matters until it is fixed, and the finding is reproducible rather than theoretical.

Then the secrets. Keys committed to the repository are the obvious case, and the version history is checked as well as the current files, because a key removed last year is still in the history and still valid unless somebody rotated it. The files a browser actually downloads are checked too, since build tools copy configuration into them and a key can be absent from the source and public anyway. We go into the mechanics of this in the article on keys that bypass your rules.

Finally, how people sign in, and what happens when they should no longer be able to. Password reset and session expiry are unglamorous and are where real incidents start.

The data model and what it will not let you do

This is the part owners underestimate and the part that costs the most to get wrong. Application code can be rewritten in pieces, quietly, over months. A data model with customers' records already in it cannot, because changing it means migrating live data while the business keeps running.

So the audit asks what the structure assumes. Whether one customer can have two of something the model allows only one of. Whether prices and currencies are stored in a way that survives a second market. Whether anything is deleted outright that a finance or legal question would later need. Whether records carry enough history to answer the question of who changed what, and when.

The output here is not a verdict on quality. It is a list of things the business plans to do next, each marked as cheap, awkward or structural under the current model.

Whether anyone else can actually run it

A codebase only one person can deploy is a liability regardless of how it is written. The test is blunt: clone the repository onto a clean machine and try to run it using only what was handed over.

• Does it build from the repository alone, without files that live on somebody's laptop?
• Is there a documented way to deploy, or is it a sequence someone performs from memory?
• Do backups exist, and has a restore ever been attempted rather than assumed?
• Are there tests, and do they cover the flows where failure costs money?
• Is anything in the stack past its security support, which turns a maintenance task into a deadline?

These are the findings that most often change a price rather than a decision. None of them means the app is bad. All of them mean the first weeks will be spent on groundwork rather than features, and it is better to know that before you agree a timeline.

When the code came from an AI builder

Apps generated by prompting are increasingly what gets inherited, and they concentrate risk differently. The code is usually conventional and readable, so the reading goes quickly. The access rules are the problem, because tables added later by prompting often arrive without the protections the earlier ones received, and the app looks consistent while the enforcement is not.

The audit is the same shape, but the order shifts: data access and keys first, structure second. If that is the situation you are in, the production checklist covers the specific checks, and the AI-built app rescue service describes the work that follows.

What you should get at the end

A useful report is short and ordered by consequence. Three or four findings that change what you should do, each with what it is, what it would take to fix, and what happens if you do not. Then everything else, grouped, explicitly marked as not urgent.

It should also contain the thing most reports omit: a recommendation. Build on it, build on it after fixing these specific things, or do not build on it, with a reason stated plainly enough to repeat to someone who has never seen the code.