You just inherited a project: a Git repository, maybe an app in production, and no one to explain how it all holds together. Before deciding anything (fix, continue, or start over), you need to know what you’re holding. That’s what an audit is for. Here’s how I go about it, in order.
What an audit has to answer
Three questions, not thirty: what works, what’s risky, and how much is left to do. Everything else follows from those.
1. Get it running
Before reading a single line, try to run the project locally. Dependencies, environment variables, database: does it start? If it doesn’t, you already have an important piece of information. A project nobody can reproduce is the first job to fix, before any feature.
2. Read the architecture before the detail
You understand a project by its overall shape, not by opening files one at a time. Look at the folder structure, the stack, the dependencies, how the pieces talk to each other. Within an hour you know whether you’re dealing with something clean and readable or a plate of spaghetti.
3. Look for the debt and the risks
A few signals speak quickly: dependencies several major versions behind, no tests on the critical paths, secrets (passwords, API keys) written in plain text in the code, abandoned “TODO”s in sensitive spots. These aren’t details. They’re what decides the cost of the weeks ahead.
4. Check what isn’t in the code
A project is more than its repository. Where does the database run? Who holds the access? How does deployment happen? Are there backups? The real fragilities often hide there, outside the code, in infrastructure nobody documented.
5. Produce a verdict you can act on
An audit that ends with “it’s complicated” is useless. By the end you should have: what’s worth keeping, what needs redoing, the risks ranked by severity, and a rough order of magnitude on time. Enough to decide, not to worry.
What a good audit is not
It’s not a rewrite quote in disguise. Someone who, after two hours, concludes you should rebuild everything is selling a rewrite, not a diagnosis. Most of the time, a good part of the code is perfectly salvageable.
Inherited code is frightening mostly because it’s unknown. Once the audit is done, it becomes a normal project again: a task list and a clear path. It’s the first step of every project rescue I take on.
Inherited a project and don’t know what it’s worth? Get an audit. I’ll hand you a clear read of where it stands and what’s genuinely left to do.
Frequently asked questions
How long does an audit take? From a few hours to two or three days depending on the size of the project. The goal is a diagnosis, not a line-by-line exploration.
Do I need to give access to everything? Ideally yes: the code, the hosting, the database. But we can start with the repository alone and fill in the rest afterwards.
Is the audit paid? A first look is free during the call. A deep audit, with a written report, is a service in its own right, at a fixed price.