Technical due diligence, defined
Updated
Technical due diligence is the assessment of a target company's technology before an investment or acquisition: architecture, code quality, technical debt, security posture, delivery capability, infrastructure, and the team behind them. Its purpose is to surface technology risk while it can still change the price, the terms, or the decision.
Tech DD is commissioned by the buyer or investor, runs inside the deal timetable, and ends in a judgment: what is this technology worth, what will it cost to fix or scale, and what could kill the thesis. Evidence-based tooling can harden that judgment; nothing yet replaces it.
What technical due diligence examines
The scope varies with the thesis — a talent acquisition, a platform bet, and a cash-flow purchase interrogate different things — but most engagements cover a recognizable core. The unifying question is not whether the technology is elegant; it is whether the technology can support the plan the price assumes.
- Architecture and scalability: whether the system's design supports the growth or integration the deal model assumes, and where the rewrite cliffs are.
- Code quality and technical debt: the condition of the codebase, the age and support status of its dependencies, and the interest the next owner will pay on every change.
- Security posture and compliance: exposure, incident history, control maturity, and the certifications or frameworks customers and regulators will demand.
- Delivery capability: whether the organization can actually ship — release cadence, stability, and the health of the path from commit to production.
- Infrastructure and cost: cloud footprint, licensing, unit economics of serving the product, and concentration risk in providers.
- Team and key-person risk: who holds the systems in their head, and what leaves when they do.
- Intellectual property hygiene: ownership of the code, open-source license obligations, and anything encumbering the asset being bought.
Consultancy-led vs platform-supported
Traditional tech DD is consultancy-led: a specialist team interviews the target's engineers, reviews samples of code and documentation, and writes a report. Platform-supported DD adds instrumentation: read-only connectors collect evidence directly from the target's repositories and infrastructure, and scoring runs on what was actually observed. The approaches answer to different constraints, and mature processes increasingly use both.
Both framings carry vendor incentives — consultancies and platforms each sell their own side of this comparison — so treat every row below, and every vendor's claims, as something to verify in your own evaluation rather than accept at face value.
| Dimension | Consultancy-led | Platform-supported |
|---|---|---|
| Primary evidence | Interviews, documentation, and sampled code review. | Read-only telemetry collected from the systems themselves. |
| Coverage | Deep on what the team sampled; silent on the rest. | Broad across connected systems; blind to anything not connected. |
| Repeatability | A new team re-deriving the analysis may reach different conclusions. | The same connectors and scoring rules produce comparable results across targets and over time. |
| Judgment | Built in — seniors interpret findings against the deal thesis. | Not included; scores inform a judgment a human still has to make. |
| Failure mode | Impressions presented as findings; conclusions the evidence cannot reproduce. | Numbers mistaken for answers; unmeasured areas mistaken for healthy ones. |
What evidence-based scoring adds
The chronic weakness of interview-driven DD is that it measures what the target chose to show and what the reviewers happened to sample — and its conclusions are hard to defend when challenged, because they cannot be re-derived. Evidence-based scoring attacks that weakness directly: connectors read the actual repositories, pipelines, and cloud accounts without write access; the same rules score every target; and the output is traceable back to the observations that produced it.
The discipline that makes such scoring trustworthy is refusal: anything the connectors cannot observe should read as not measured rather than being estimated. In a diligence setting that refusal is the point — a target that cannot be measured is a finding in itself, and an extrapolated score would launder exactly the uncertainty the diligence exists to expose. When weighing any evidence-based tool, confirm that its coverage is stated explicitly, its rules are applied identically across every target, and its output traces back to the observations that produced it.
What it cannot replace
No score reads intent. Instrumentation can show that a service is a decade old and heavily patched; only a conversation reveals whether that is prudent stewardship of a stable cash cow or the wreckage of three abandoned rewrites. It cannot assess whether the architecture fits the acquirer's strategy, whether the team will stay through an earn-out, whether an open-source license question needs counsel, or how the integration should actually be sequenced.
Platform-supported evidence changes what the humans spend their time on, not whether they are needed. The strongest diligence uses measurement to make the interviews adversarial in the good sense — walking in with the target's own telemetry, spending the limited hours on the anomalies rather than on establishing basic facts. The judgment at the end of the engagement remains a human's, and should.
Frequently asked questions
What does technical due diligence cover?
Typically architecture and scalability, code quality and technical debt, security posture and compliance, delivery capability, infrastructure and cost, team and key-person risk, and intellectual-property hygiene — scoped to the deal thesis, since a talent acquisition and a platform bet interrogate different risks.
Who performs technical due diligence?
Usually a specialist consultancy or the investor's own technical team, commissioned by the buyer. The target participates by granting access and answering questions. Platform tooling can supply evidence to either side, but the engagement and the conclusions belong to humans accountable to the deal.
How is technical due diligence different from a security audit or penetration test?
Scope and question. A security audit or pen test asks whether the system is secure against defined criteria or attack. Tech DD asks a business question — can this technology support the plan the price assumes — of which security is one input alongside debt, delivery, cost, team, and IP.
Can technical due diligence be automated?
The evidence-gathering can be, substantially: read-only connectors and consistent scoring replace weeks of fact-establishment and make findings reproducible. The judgment cannot — intent, strategy fit, team risk, and license questions still require humans, and unmeasurable areas must be reported as unmeasured, not scored.
What red flags does technical due diligence look for?
Commonly: dependencies past end of life, systems only one person understands, a delivery pipeline that cannot ship safely, security posture inconsistent with what sales has promised customers, cloud costs that scale faster than revenue, and unclear ownership or restrictive licenses in the codebase being purchased.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.