Code Audit Before Changes: What to Check and How Much It Costs
A practical code-audit checklist before hiring a new developer or starting a major change.
In brief
- • An audit reduces the risk of estimating a project blindly.
- • Review access, environments, data, and release process—not only source code.
- • A useful audit ends with risks and priorities, not just a list of comments.
ContentsShow sections
Before a major change, you need to understand the condition of the project. Otherwise, an estimate may cover only the new feature while the team later discovers old dependencies, undocumented access, or an unreliable database.
A code audit is a focused investigation before deciding whether to change, rewrite, hand over, or stabilize a project.
What to check first
Structure and startup
- how the project runs locally and on the server;
- where source code, builds, and configuration live;
- which environments exist: development, test, and production;
- how releases and rollbacks work.
Dependencies and data
- framework, library, and runtime versions;
- stale or unnecessary dependencies;
- database structure and migrations;
- backup and recovery procedures;
- external APIs, payments, email, and background jobs.
Access and security
Passwords must not be stored in source code. Review access to the repository, server, database, file storage, and analytics services. For every access, identify an owner and a revocation method.
What the audit should deliver
| Area | Useful output |
|---|---|
| Risks | Issue, likely impact, and urgency |
| Changes | What can be changed safely and what depends on it |
| Plan | Stages with verification points |
| Handover | Missing access and documentation list |
VibeMarket's planning benchmark for an independent vibe coder is 1,500–4,000 ₽ per hour. Start with a bounded scope: one repository, one environment, and selected critical flows. Then decide whether a full audit is needed.
When an audit is especially useful
- the project is moving from one developer to another;
- changes repeatedly exceed the original estimate;
- each release introduces new errors;
- backup confidence is low;
- the project works, but nobody can explain how.
Do not ask for “an audit of everything” without a decision in mind. Define the question: can payments be added safely, is an architecture change reasonable, is the project ready for load, or is the documentation sufficient for a handover?
For the next step, see project support or request an audit and development work.
How to audit on a limited budget
Not every project needs every line reviewed. For both client and freelancer, start with a time-box: for example, one or two working days for startup, critical flows, and a risk list. This reveals the system's condition and shows whether a deeper audit is justified.
Define the scope first: repository, test environment, one production flow, database, integrations, or release process. If part of the system is inaccessible, record it as a limitation instead of implying it was checked.
A client-ready report structure
| Section | What to write |
|---|---|
| Summary | Whether a change can start safely |
| Critical risks | What may cause data, money, or access loss |
| Technical debt | What slows work without blocking launch |
| Plan | Which fixes come first and why |
| Next stage | What can be estimated after the audit |
Show 1,500–4,000 ₽ per hour as a work rate, not as a price for “an audit in general.” Estimate the hours for project introduction, startup, scenario checks, analysis, and recommendations. If the scope is unclear, fix only the diagnostic stage first.
Red flags in an audit offer
- the auditor promises a security verdict without environment access;
- the report has general words but no files, flows, or priorities;
- every note is marked critical without impact assessment;
- the proposal is a full rewrite without comparing stabilization;
- there is no way to verify that a recommendation was completed.
Turn the audit into useful work
End with two or three clear routes, not “more hours.” For example: fix access and backups first, stabilize billing next, and then add a feature. Clients decide more easily when they see the connection between risk, action, and result.
This also protects the freelancer from accepting a project blindly. When the codebase cannot be estimated honestly, a paid audit is a proper first stage, not free preparation for unknown work.
The audit in one paragraph
A useful audit does not answer whether code is “beautiful.” It answers what may happen when the next change is made. The client should know which risks to accept, which to fix first, and what the safe next step costs. The freelancer should know what evidence supports the conclusion and where the checked scope ends.
If unknowns remain, list them. An honest limitation list is more valuable than a confident report that never checks production and real user data.