Technical due diligence
Technical due diligence is a structured assessment of an existing software system, its code, architecture and delivery practices, carried out to answer a specific commercial question. That question is usually whether the system can be safely supported and extended, or whether it should be rebuilt.
Also known as: Code audit, Tech due diligence, Codebase review, Technical audit
Last reviewed
Why technical due diligence matters
Software is bought, inherited and taken over regularly — in an acquisition, when a supplier relationship ends, when a founder leaves, or when a project has stalled and someone has to decide what happens next. In each case a large commitment is about to be made on the basis of a system nobody independent has examined.
The review exists to put a defensible answer under that decision. The cost of the assessment is small against the cost of being wrong, and being wrong here is expensive in a particular way: you usually only discover it after committing to support something that cannot be supported.
What a review examines
A good review is scoped to the commercial question rather than producing an exhaustive critique. Typically it covers the code — structure, consistency, test coverage, whether a new developer could work in it; the architecture — whether it will hold at the volumes intended; security and data protection, including how credentials and personal data are handled; dependencies, and whether anything critical is out of support; operations — deployment, monitoring, backups, and whether it can be released without drama; and knowledge, meaning documentation and how much only exists in one person's head.
The output should be a recommendation with reasoning and a costed path, not a list of findings for you to interpret.
Technical due diligence vs a code review
A code review is part of normal development: a colleague checks a specific change before it merges, continuously, as a quality practice.
Technical due diligence is a one-off assessment of a whole system carried out to inform a decision, usually by someone independent of the team that built it. The distinction matters when commissioning: asking the incumbent team to review their own work produces a document, but not an independent answer, and it is the independence that the decision actually rests on.
When you need it
Before acquiring a company whose product is software, before taking over a codebase from another supplier, when a build has stalled and you need to know whether to continue, or before committing significant investment to extending an existing system.
It is deliberately priced as planning rather than as a project. Our fixed-fee App Rescue Assessment answers the single commercial question — can this be safely supported, stabilised, used as a prototype, or should it be rebuilt. A Standard assessment is £3,000 + VAT, smaller apps can be less from around £1,500, and larger or more sensitive systems more at £5,000 to £8,000+. Most complete within a few working days once we have repository and demo access.
Technical due diligence: common questions
Code structure and test coverage, architecture and whether it scales, security and data handling, dependencies and whether any are out of support, operational readiness such as deployment and backups, and how much knowledge exists only in someone's head. It should end with a recommendation, not a list of findings.
Our Standard App Rescue Assessment is £3,000 + VAT, with smaller apps from around £1,500 and larger or more sensitive systems £5,000 to £8,000+. Most complete within a few working days once we have repository and demo access, because it is scoped as planning rather than a full project.
They can produce a document, but not an independent answer, and independence is what the decision rests on. A team assessing its own architecture cannot easily conclude that it should be replaced. Where budget is tight, an independent review of the riskiest area beats a full internal one.
Yes. We review modern web, mobile and AI codebases, including apps built with AI and no-code tools, and those are increasingly common subjects. If your stack is not one we have listed, it is worth asking — we are usually happy to take a look.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.