09Technical Due Diligence
Know what you are buying before you buy it.
A structured assessment of a target’s software, infrastructure, security posture, delivery capability and licensing, written for the deal team and for the engineers who will own the result.
01Where it starts
What we usually walk into.
Technology is a growing share of what gets acquired, and the diligence on it is often a management presentation and a repository tour. The expensive surprises — an unmaintainable core, a licence problem, a security posture that fails the first customer review — appear after completion.
We are acquiring a company and the technology is most of the value; we cannot assess it ourselves.
The data room has architecture diagrams and no evidence they describe the running system.
We need to know whether the platform can integrate with ours, and what that would cost.
The target claims security certifications and we want to know what sits behind them.
The deal timetable gives us two weeks, and the report has to stand up in negotiation.
02Approach
How we do the work.
We assess the estate against evidence: code, architecture, infrastructure, delivery data, incident history, security controls and licence inventory, with the people who run it. Findings are rated by their effect on value, integration and risk, and written for two audiences.
- 01
Evidence, not narrative
We read the code, the pipelines, the infrastructure definitions, the incident history and the delivery metrics, and we interview the engineers who own them. Every conclusion is traceable to something we observed.
- 02
Rated by effect on the transaction
A finding is described in terms of value, integration cost and risk to the business case — not as a technical opinion. Twelve findings that matter beat two hundred that do not.
- 03
Security and licensing in scope by default
Security posture, open-source licence compliance and supply-chain exposure are assessed in every engagement. These are the findings most likely to become warranties and indemnities.
- 04
Two readers, one document
An executive summary for the deal team, full technical reasoning for the engineers who will inherit the estate, and a list of conditions and post-completion actions with effort estimates.
Capabilities and deliverables
Capabilities
- Code and architecture assessment
- Infrastructure and operability review
- Security posture assessment
- Open-source licence and supply-chain analysis
- Delivery process and capability assessment
- Integration and cost-to-own modelling
What you receive
- Technical due diligence report with findings, evidence and ratings
- Architecture and infrastructure assessment
- Security posture assessment against the claims made
- Open-source licence inventory and compliance findings
- Delivery capability and key-person dependency assessment
- Integration cost and post-completion action plan
- Deal-team briefing and Q&A session
Common use cases
- Acquisition of a software or technology-dependent company
- Investment round where technology is the principal asset
- Post-completion technical integration planning
- Vendor due diligence ahead of a sale
- Independent review of a major platform commitment
Technologies typically involved
- Stack-independent — whatever the target runs
- Common estates: Java, .NET, Go, Python, Node.js, PHP
- Cloud: AWS, Azure, Google Cloud, on-premise and hybrid
- Tooling: Semgrep, Trivy, licence scanners, delivery analytics
03Engagement
How it runs.
- 01
Scoping
2–3 days
Transaction context, estate size, data-room access, timetable and the questions the deal team needs answered.
- 02
Assessment
1–3 weeks
Code, architecture, infrastructure, security, licensing, delivery data and management interviews.
- 03
Report and briefing
1 week
Written report for both audiences, deal-team briefing, and support during negotiation.
- 04
Post-completion
On request
Optional: integration planning and a first-hundred-days technical plan with the acquired team.
04Security
Security considerations.
These apply to this service specifically. They are engagement conditions, not aspirations, and we will put them in the contract.
- All material is handled under NDA and destroyed on an agreed schedule
- Findings are shared only with the named recipients you nominate
- No testing against the target’s live systems without written authorisation
- Conflicts of interest are declared before scoping; we do not advise both sides
05Outcomes
What changes afterwards.
A defensible view of the technical asset, the cost to own and integrate it, and the conditions worth putting in the agreement.
- 01
A technical view that stands up in negotiation, with evidence behind every finding
- 02
Integration cost and post-completion work estimated before the price is agreed
- 03
Security and licence exposure known before it becomes a warranty claim
- 04
A plan the inheriting engineering team can act on from day one
06Questions
Asked before every engagement.
Two to four weeks for most transactions, depending on estate size and data-room access. A compressed one-week version covers the highest-risk areas where the timetable requires it, with the reduced confidence stated explicitly in the report.
It makes a large difference. Code and diagrams tell you what was built; the engineers tell you what breaks, what is avoided and who holds it together. Where interviews are not possible we say so, and rate the affected findings accordingly.
Specific, with evidence. A report that says "technical debt exists" is not useful in negotiation. Ours says which components, why they matter to the business case, what it would cost to address them, and what conditions are worth including in the agreement.
Either, never both on the same transaction. Vendor due diligence — preparing an estate for scrutiny before a sale — is the same assessment run early, so the answers exist before the questions are asked.
Frequently runs alongside
Ready to scopetechnical due diligence?
Bring the problem, the constraints and the deadline. We will tell you what is achievable, what it costs and what we would do first.