A technical problem that cannot be costed is not evidence; it is an opinion with a page number.
Why the review exists at all
Deals fail on technology more often than the deal documents admit, and they fail once the deal has closed, when the acquirer owns the problem and has lost the negotiating position that would have set the terms. MEV's guide reports that 62 per cent of deals fall below their financial targets, most often because diligence was weak, and the same guide records a global average data breach cost of $4.99 million, 12 per cent higher than the previous year and the highest on record. That money does not come out of the seller's pocket once the ink is dry. It comes out of the buyer's. A technical review is the only part of the diligence stack that can turn that exposure into a number before the funds are committed, which is why we treat it as a costing exercise rather than a compliance ritual.
The same term, two trades, one method
The vocabulary has converged across two industries that rarely read each other. RICS sets out a professional standard for technical due diligence of commercial property, and that standard records that the term technical due diligence is generally adopted by the industry, that building survey, building condition inspection, pre-acquisition survey and vendor survey are also in use, and that the term structural survey should not be used at all. In software and technology M&A, the same phrase covers the engineering review of a codebase, its infrastructure, its security posture, its licensing position and its team. Both trades inspect an asset they did not build, on a deadline they did not set, for a client who will own the consequences. That is why we treat the two as one subject rather than two.
What the review actually tests
A software review covers five areas, and they are not equal in weight. Codebase quality is the question of whether the code can be maintained, scaled and documented well enough for someone other than its author to change it safely. Infrastructure is the question of whether the systems it runs on are reliable and can grow. Security and compliance turn on whether data is protected and whether the operation meets the rules that apply to it. Team evaluation weighs whether the skills, processes and judgement exist inside the company or only inside one person's head. Roadmap alignment determines whether the technology can support the business plan the buyer is paying for, which is the only question the board will remember afterwards. Zartis's checklist makes the regulatory point sharply: non-compliance under GDPR can attract fines of up to 20 million euros or 4 per cent of annual global turnover, an amount large enough to change the shape of a deal rather than merely adjust it.
The order of the work, and why it matters
MEV's framework consists of three parts, and no subsequent reading has improved upon it. The first defines the desired state against the buyer's business goals, so that the review has a standard to fail against. The next audits the current state of the code, the infrastructure and the team. The last measure calculates the gap between the two and assigns a cost to it. Without the first step, the audit results in an inventory and the costing results in an argument. Roman Beylin, founder of DueDilio, describes the discipline of that last step plainly in MEV's guide:
In my opinion, the goal isn't to answer every technical question. It's to identify the handful of issues that could materially impact the business after closing.
That is the standard we hold reviews to. A comprehensive report that fails to prioritise findings shifts the risk from the seller's balance sheet to the buyer's reading list.
Commands that answer questions, not commands that decorate a report
Much of what a review needs is already sitting in the repository, and it costs an afternoon rather than a fortnight. These four commands settle four questions that recur in every engagement, and they produce artefacts that legal and financial diligence will request anyway.
git shortlog --summary --numbered --since="24 months ago" | head -20
git log --format='%ad' --date=short | cut -c1-7 | sort | uniq -c
npm ls --all --json > dependency-tree.json
pip-licenses --format=csv --with-license-file --output-file licences.csv
The first two cover bus factor and liveness: whether one committer was responsible for most of the system over the last two years, and whether the repository is still being worked on at a normal rate or has gone quiet since the founders started preparing for the sale. The other two produce the dependency and licence inventory. Open-source licence obligations are a familiar source of unpleasant surprises after a deal closes, and DFIN's guide to technical due diligence lists ignoring open-source licensing constraints and neglecting key-person dependencies among the most common pitfalls in the process. Both are visible in the evidence above, and both are cheaper to deal with before exchange than after.
What changes a valuation
Four kinds of problem change a valuation rather than merely annoy the buyer. A system that cannot scale to the buyer's growth plan converts an acquisition into a rebuild, and the rebuild is funded by the buyer. A security or compliance failure imports fines, notification costs and customer churn into a business the buyer has just bought. Technology bought for its appearance rather than its function, which MEV's guide calls overhyped technology used to drive a valuation, has no residual value once the marketing effect wears off. And outdated or manual processes act as a tax on every future release, with MEV's guide reporting that technology debt consumes 10 to 20 per cent of the new-product budget at the companies its research covers. Each of those is a number, and each of those has to appear in the report as a number.
What the property side does differently, and what it does identically
Commercial property diligence reaches the same conclusion by a different route. Savills sets out its technical due diligence work as starting with a building survey and extending into assessment of specifications and drawings, benchmarking against industry standards, reviewing repairing obligations under leases, reviewing legal contracts, preparing budget schedules and negotiating on the client's behalf. TFT makes the operational point that building services such as heating and cooling, ventilation, building management systems and drainage often present greater problems than the building fabric itself, and that those problems are frequently not visible. GoReport draws the boundary between a standard building survey, which assesses overall condition, and technical due diligence, which evaluates risks and liabilities, long-term maintenance and operational costs, and regulatory compliance. Workman frames the commercial test used for both trades: a review is worth what it changes about the decision, the advice has to summarise the risk, set out the options and recommend something the client can act on, and a single named point of contact has to own the work from instruction through to the report a board can put its name to.
Sources
- Technical Due Diligence Guide: Process, Checklist & Red Flags
- Technical due diligence of commercial property, 1st edition
- Technical Due Diligence | Savills UK
- Technical Due Diligence Checklist – When and How to Perform One | Zartis
- The Complete Guide to Technical Due Diligence (TDD) | Go Report
- Technical Due Diligence | DFIN
- Commercial Property Technical Due Diligence Services | Workman
