A technical audit is a read of a software system by someone who has no stake in how it was built. It answers three questions: what condition is this in, what would it cost to keep going as is, and what would it cost to fix the parts that matter. It is not a code review and it is not a witch hunt.
Most owners commission one too late, usually after a project has already failed. The moments below are cheaper.
Key takeaways
- It reads evidence, not opinions: Repository history, deploys, tests, dependencies and the system running.
- It costs your team a day, not a month: A good audit works from access, not from interviews.
- Five moments make it pay for itself: Acquisition, handover, a stalled project, before a major investment, and after losing key people.
- The output is decisions, not a severity list: A report you cannot act on was not worth commissioning.
What an audit actually covers
The system as it runs. Set up from scratch following whatever instructions exist, then used. How long setup takes and how many undocumented steps are needed is itself a finding.
The repository history. Who has worked on it, how often, whether changes are small and frequent or large and rare, which areas have been rewritten, and where activity has stopped.
Tests and deployment. Whether automated tests exist, whether they run, whether anyone trusts them, and how a change gets from a developer's machine to production.
Dependencies and security. Which components are out of support, which have known vulnerabilities, and whether secrets are stored the way they should be.
Data. How the data is structured, whether it is consistent, and what it would take to move it somewhere else. This is usually where the expensive surprises are.
Concentration of knowledge. How much of the system only one person can safely change.
The five moments it pays for itself
1. You are buying a company or a product
The software is often a large part of what you are paying for, and a valuation built on revenue can be undone by a system that cannot be changed. An audit before signing is cheap relative to the number on the contract.
2. You are taking over from another team
Whether the relationship ended well or badly, you need to know what you are inheriting before you commit to a plan. This is the highest-value moment for most businesses, and it is covered in more detail in taking over a codebase from a team you no longer trust.
3. A project has stalled and you cannot tell why
The reports are fine, the dates keep moving, and you have no way to test either. An audit replaces the argument about what is true with a set of observations, which is usually enough to unstick the conversation.
4. You are about to spend significantly more
Before committing to a large next phase, it is worth knowing whether the foundation will carry it. The most expensive version of this mistake is building a year of new work on something that needed replacing at the start.
5. You have lost the people who built it
When the person who understood the system leaves, the knowledge leaves. An audit converts what is left into something written down, and it is much easier to do while some of the team remains.
What a useful report looks like
The output should be readable by you, not only by an engineer. Expect: a plain summary of condition, a short list of things that are genuinely risky with the business consequence of each, an estimate of what it would take to address them, and an explicit statement of what is fine.
That last part matters. An audit that finds everything alarming is not an audit, it is a sales document. A good one tells you which parts to leave alone, because that is where most of your budget gets saved.
Expect a ranking too. Nobody fixes everything, so the report should say what to do first, what to do if you are keeping the system for another three years, and what only matters if you plan to scale.
What it costs you
The direct cost varies with the size of the system. The cost people forget is team time, and this is the part worth negotiating. A well-run audit works primarily from access: repository, issue tracker, deployment logs, a test environment. Your engineers should spend about a day answering questions, not a month in workshops. If a proposed audit requires weeks of your team's involvement, it is consuming the capacity it was meant to protect.
Ali Boran Gazel