Code Audit and Documentation
A structured review of an application's code, architecture and dependencies, delivered as a plain-language report and written documentation, for businesses that want an honest picture of their software without committing to fixing it yet.
What This Engagement Delivers
Unlike maintenance or a rescue, the deliverable here is the report and the documentation themselves, not changes to the running application. It suits a business that wants clarity before deciding what to do next.
What We Review
Code Quality and Architecture
How the codebase is structured, how consistently it follows its own conventions, and how easily it can be changed safely.
Security Exposure
Known vulnerabilities in dependencies, weak points in access control, and any credentials or keys stored insecurely.
Dependencies and Versions
How far the runtime, framework and libraries are from current, supported versions.
Database and Hosting
How the data is structured and backed up, and whether the current hosting setup matches what the application actually needs.
What the Documentation Covers
- An architecture overview describing how the major parts fit together
- Environment setup steps needed to run the application from scratch
- The deployment process, written down rather than known only from memory
- An inventory of accounts, services and third-party integrations in use
How the Report Gets Used
The report is written to be read by someone without a technical background, with risks ranked by business impact rather than technical severity alone. It is commonly used to brief a new developer, decide between maintaining and rebuilding, or simply to know what condition the software is actually in.
Frequently asked questions
Does an audit include fixing what's found?
No, not by default. An audit produces a report and documentation; fixing what it finds is a separate piece of work, whether that is a one-off engagement or an ongoing maintenance arrangement.
What decides the cost of a code audit?
The size of the codebase, how many areas are in scope, code, security, database, hosting, and how much of it lacks any existing documentation to start from.
What decides how long an audit takes?
The size and age of the codebase, and how much has to be reconstructed, such as a missing local environment, before a proper review can even begin.
Do you need our source code and server access for an audit?
Yes, read access to the code, hosting and database is needed to review them properly rather than relying on secondhand descriptions of how they work.
Who can read the audit report?
It is written for you and anyone you choose to share it with, whether that is your internal team, an incoming developer, or a business partner deciding whether to invest further.
What if the audit finds the application should be rebuilt?
We say so directly, with reasons, and describe what a partial or full rebuild would involve. The audit is not sold on the assumption that maintenance is always the right answer.
Do you provide documentation without a full audit?
Yes, where the code is already in reasonable shape and the main gap is simply that nothing was ever written down about how it works.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private