Article
Most of the codebases we take over were built by someone who is no longer around: a previous agency, a departed founder, an engineer who has moved on, or lately, a tool that generated them faster than anyone read them. The first week is an audit, and it is the same eight questions every time. The order matters, because the early answers change how much the later ones are worth.
1. Can we build and run it from a clean machine?
Not "does it run on the laptop it was built on". A fresh clone, the documented setup steps, and a stopwatch. If this takes more than a morning, every later estimate is wrong by the same factor, because every engineer who joins will pay it. The fix is usually a container definition and a script, and it is the first thing we do.
2. Where are the secrets?
In the code, in the history, in a shared document, or in a vault. Secrets in the repository are a rotate-everything event before anything else happens, and they tell you the previous team did not have a review step that would have caught it.
3. What does the data look like, and does it match the code?
We read the schema, then sample the tables. Columns that are always null, foreign keys without constraints, dates stored as strings, and a status field with fourteen distinct values where the code handles four. The distance between what the code expects and what the data contains is the size of the bug backlog nobody has filed yet.
4. What is tested, and does it pass?
A test suite that exists but is skipped in CI is worse than none, because it gives false comfort. We run it, count what is green, and look at what the green tests actually assert. Then we identify the three paths that would cost the business the most if they broke, and check whether anything protects them. Usually nothing does, and that is the first week of real work.
5. Which dependencies are abandoned or unpatched?
A dependency list with dates tells a story. Frameworks two major versions behind, libraries whose last release was years ago, and a lockfile that has not moved since launch. Each one is a future forced upgrade, and some are current vulnerabilities.
6. How does it get to production, and how does it come back?
Deployment by hand from one person's machine is common. So is no rollback plan. We ask how the last three deploys went and whether anyone can name the current production version. The answers predict how safely we can make changes in the first month.
7. What does it do that nobody wrote down?
Cron jobs, scheduled emails, webhooks from third parties, an integration that runs on someone's desktop. We list every entry point into the system and every scheduled thing it does, because these are what break silently during a migration.
8. What does the business think it does?
Finally, we talk to the people who use it. The gap between the code's behaviour and their description of it is where the undocumented rules live, and those rules are the part that must survive whatever we do next.
What the audit produces
A written list, ranked by risk, with a cost against each item. Security and data problems first, then the untested critical paths, then everything else. The owner decides what to fix, in what order, and with whom. That document is more useful than any estimate we could give before writing it, which is why we do not give one.