An agency leaves mid-project, a contractor disappears, or a founder's first developer moves on. What remains is a codebase that partly works, with little documentation and no one who remembers why it was built that way. Deciding what to do next on a guess is expensive. A code audit replaces the guess with evidence.
This guide covers what a code audit should examine when you take over a half-finished codebase, in the order that gives answers fastest, and how to turn the findings into a decision: continue, repair or rebuild.
Start With Ownership and Access
Before reading any code, confirm you can legally and practically control the project.
- Who owns the code, designs and data under the original contract? Our list of questions to ask a software agency before signing explains what good terms look like.
- Do you have the repository, with its full history, in an account you control?
- Do you have the cloud, domain, app store, payment and email accounts?
- Are there licence or open-source obligations that affect you?
If the answers are unclear, fix them first. Everything else depends on them.
Can It Be Built and Run?
A codebase nobody can run is a liability. Check:
- Can a new developer set it up from the instructions in under a day?
- Does it build from a clean checkout, with pinned dependency versions?
- Is there a deployment process, and can you reproduce it?
- Which environment variables and external services does it need?
If setup depends on one person's laptop, treat that as the first finding.
Architecture and Structure
Read how the system is organised, not every line.
- Is there a consistent structure, or several competing styles?
- Where does business logic live: in a clear layer or scattered through the interface?
- How do the parts communicate, and is data duplicated?
- Does the design match the product's needs, such as multiple customers or roles? Our guide to multi-tenant SaaS architecture shows a decision that is costly to change late.
Inconsistent structure raises the cost of every future feature.
Code Quality and Tests
- Are there automated tests, and do they pass?
- Is the type system used properly? Our article on TypeScript patterns that prevent bugs in production lists the checks to look for.
- Is there duplicated or dead code?
- Are errors handled, logged and surfaced?
- Do linting and formatting rules exist and run?
No tests does not mean the code is bad, but it means every change carries risk until some are added.
Security
- Are secrets, such as keys and passwords, stored outside the code and absent from the git history?
- Are inputs validated, and are database queries parameterised?
- Does authentication use a standard approach, and is access checked on the server?
- Are dependencies known to have vulnerabilities?
A secret found in the repository history must be treated as exposed and replaced.
Dependencies
List frameworks and libraries, their versions and their maintenance status. Outdated or abandoned packages are future upgrade work, and deprecated frameworks can force a larger migration.
Data
- Where is data stored, and is it backed up and restorable?
- Is there a schema definition and a migration history?
- Does the data contain personal information, and how is it protected?
Data is often the most valuable asset in the project and the hardest to repair.
Completeness
Compare what exists with what was promised. Build a list of features that are done, partly done and not started, and note where the code works but the behaviour is wrong.
From Findings to Decision
Group findings by severity and effort, then choose a path:
| Situation | Usual path |
|---|---|
| Clean structure, gaps in tests and features | Continue, add tests, finish the build |
| Sound core, specific weak areas | Repair the weak areas, then continue |
| Wrong architecture for the product, or unrunnable code | Rebuild the affected parts, reusing the designs and data |
Rebuilds fail more often than they are warranted, so ask whether the problem is the codebase or the missing documentation and process around it.
Frequently Asked Questions (FAQs)
How long does a code audit take?
A focused audit of a small or medium codebase commonly takes several days to two weeks, depending on size and access.
Who should run it?
Someone independent of the original team, with experience in the same stack. An outside view finds issues the previous team had stopped noticing.
Should I stop development during the audit?
Yes, unless the work is separate from the code under review. New features on an unknown base add to the problem.
Conclusion
A code audit tells you who owns the project, whether it runs, how it is built, how safe it is and how much is finished. With those answers, the choice to continue, repair or rebuild is a business decision backed by facts.
If you have inherited a project and need an independent assessment, see our custom software development services or contact us.