How to Prepare Your Codebase for a Code Audit: What to Clean Up Before We Start
Somewhere between signing the engagement and the auditor's first day, most teams do exactly the wrong thing: they scramble to make the codebase presentable. This post covers code audit preparation as we wish every client approached it. The two weeks before an audit decide how useful the final report will be, and almost none of that time should go into polishing code. It should go into access, documentation, and honest context. A prepared client gets findings ranked against their real risks. An unprepared one pays the auditor to reverse engineer things the team could have written down in an afternoon.
We have written before about what a full application audit examines and how to tell your codebase needs one. This is the practical companion. You have decided to commission an audit, the start date is on the calendar, and you want the most for your money.
Code audit preparation: the two weeks before the start
Four pieces of groundwork matter more than everything else in this window. None of them involve changing production code.
A running environment the auditor can actually use
The most common delay in audit engagements is environment setup. If a new developer needs three days and two chat threads to get your application running locally, the auditor will burn the same three days, and you are paying for every one of them.
Before the start date, have someone who did not build the setup follow your README on a clean machine. Fix whatever breaks. Docker helps, but the tooling is secondary. What counts is that "clone, install, run, log in" works without tribal knowledge. If a realistic local environment is out of reach because the system depends on data or services you cannot replicate, say so up front and prepare a staging environment with representative data instead. An auditor who can only read code, and never run it, will still find plenty, but the findings about performance and actual behaviour under load will be weaker.
A one-page description of the deployment pipeline
Write down how code reaches production: what triggers a build, what CI runs and what it skips, who is allowed to deploy, how database migrations are executed, and what rollback looks like in practice rather than in theory. One page is enough.
If writing this page turns out to be hard, that difficulty is itself a finding, and it is better that you discover it than the auditor. Teams are often surprised by their own answer to "what runs between merge and production." The page also saves the auditor from having to infer the pipeline from CI config files, which takes longer and misses the informal steps.
A shortlist of the modules that worry you
Auditors prioritize, because no audit reads every line with equal attention. You know where the bodies are buried: the billing module nobody wants to touch, the permission checks that grew organically, the 4,000-line service class that three developers have quietly refused to modify. Name these areas explicitly and the audit will spend its depth where your risk actually sits.
Some clients hesitate here because pointing at weak spots feels like confessing. It is the opposite. Every hour the auditor does not spend discovering what you already knew is an hour spent on what you did not.
The incident history
Gather the production incidents from the last twelve months. If you write postmortems, collect them. If you do not, a plain list is fine: date, symptom, what fixed it. Incidents cluster around the same architectural weaknesses, and that clustering tells an auditor where to dig in a way no static analysis can.
What your auditor needs from the team
Beyond the groundwork above, a good auditor will ask for four things before day one.
The original requirements, in whatever form they survive. The codebase implements decisions, and without the requirements behind them, an auditor cannot distinguish deliberate trade-offs from accidents. Old tickets, a spec document, even a recorded walkthrough with the founder all work.
The known problem areas, written down by the people who work in the code daily. This overlaps with your worry shortlist but goes wider: flaky tests, slow endpoints, weird data in old rows, that one cron job nobody understands.
The current test strategy and its tooling. Not just the coverage number, but which suites exist, what runs in CI versus locally, and whether the team trusts a green build enough to deploy on it. An auditor reads test quality very differently when they know the team treats the suite as decoration.
Read access to the production monitoring stack, whatever it is. Error tracking, logs, metrics dashboards. Ten minutes in a real error tracker often reorders an audit's priorities more than a day of code reading.
One more thing, and it is the cheapest on this list: name a contact person who can spend two or three hours a week answering questions during the engagement. Audits stall on unanswered questions more than on technical obstacles.
What not to do before an audit
Two preparation instincts actively damage the result, and both are common.
Do not clean up to hide technical debt. Auditors have seen everything: the commented-out blocks, the TODO from 2019, the copy-pasted controller. A cosmetic sweep the week before the audit will not conceal any of it, because the structure underneath is what gives it away. What the sweep does accomplish is pollute the git history right before someone starts reading it, and git history is one of the audit's richest sources. Churn maps, blame records, and commit patterns show how the team really works with the code. Bury that under a thousand-file formatting commit and you have paid to have your own evidence destroyed. The debt is what you are commissioning an assessment of. Let it be seen.
Do not update dependencies right before the audit. A fresh framework or library upgrade makes it hard to tell which problems have been in the system for years and which arrived last Tuesday. The audit ends up attributing behaviour to the wrong era of the codebase, and remediation priorities come out wrong. If an upgrade is urgent for security reasons, do it and tell the auditor. Otherwise freeze dependency changes from two weeks before the start until the report is delivered.
Normal feature work can continue throughout. An audit reads a snapshot plus history; it does not require the code to hold still.
Turning findings into a remediation backlog
A useful report arrives with severity-ranked findings and remediation recommendations. The translation into an actual backlog is where prepared clients pull ahead again, because they can map each finding onto the context they gathered: which module it touches, which incidents it explains, who owns that area.
Resist the urge to schedule everything. Take the criticals first, security issues above all. Then look for the findings that block other findings, since fixing a tangled dependency graph often makes ten downstream items cheaper. Give each accepted finding an owner and a rough size, put the result next to your feature roadmap, and decide the split deliberately instead of letting urgency decide it for you. Then revisit the report after ninety days, because a report nobody rereads changes nothing.
If the findings point toward a longer modernization effort rather than a list of fixes, that is a different kind of project, and we have described how we approach it under legacy code optimization.
The questionnaire we send before every audit
Before each engagement, Wolf-Tech sends the client a short questionnaire. The answers shape the audit plan, and the questions double as a self-assessment you can run today.
- What prompted the audit, and what decision will its findings inform?
- Who built the system originally, and who from that group still works on it?
- Which parts of the application does the team avoid touching, and what happens when they cannot avoid it?
- When did you last deploy, and how long did the deployment take end to end?
- What happens when a deployment goes wrong?
- Which module would hurt most if it failed on a Friday afternoon?
- What do you already know is broken and have chosen to live with?
- What was the worst production incident of the past year, and what changed afterwards?
- What test tooling runs today, and does the team trust a green build?
- If the audit could answer only one question with certainty, what would you ask?
Clients who answer these carefully get a sharper audit, because the plan starts from their risks instead of from generic checklists. Clients who answer "not sure" a lot get something valuable too: a preview of what the discovery interview will surface.
If you are heading into an audit, or trying to decide whether you need one, our code quality consulting page describes how we run these engagements. And if you want a second pair of eyes on your preparation itself, write to hello@wolf-tech.io or find us at wolf-tech.io. Bringing us a well-prepared codebase does not lower the bill by magic, but it does mean the bill buys findings instead of setup time.