Technical due diligence for investors and acquirers
Technical due diligence for investors answers one question: what will this technology cost you after the deal closes that isn’t in the model yet? I give PE firms, VCs and corporate acquirers an independent, hands-on read of a target’s code, platform and engineering team, written for the people making the investment decision.
I’ve been on the other side of the table – CTO through an acquisition, and co-founder of a software studio that was sold – so I know what targets tend to present well and what they tend to leave out.
What the deliverable gives you
A report built for the deal team, not for engineers. Every finding is tied to money, time or risk.
- An executive summary in plain language: the overall view, the three to five findings that matter, and whether any of them should change price, structure or conditions.
- A risk register with each issue rated by severity and likelihood, with an indicative cost and timeline to fix.
- Key-person risk – who holds the knowledge, how much of the system depends on one or two people, and what retention matters.
- Scalability against the plan – whether the platform can support the growth in your investment case, and where it will break first.
- Security and data handling – access control, secrets, dependency hygiene, history of incidents, and how customer data is stored and separated.
- IP and licensing flags – evidence of who owns the code, open source licenses with obligations, and reliance on contractors, for your lawyers to confirm.
- A first-priorities plan – what the new owners should fix or fund first.
How I do it
I read the code. Interviews and architecture diagrams tell you what the team believes; the repository, the deployment history and the incident log tell you what is true. A review normally includes:
- Document request and kickoff – architecture overview, org chart, infrastructure bills, incident history, roadmap.
- Read-only access to source control, CI, cloud console and error tracking, usually through a clean room or supervised session if the target prefers.
- Interviews with the CTO and two or three engineers, separately where possible.
- Hands-on review of the code, data model, deployment pipeline, dependency health and infrastructure costs.
- Draft findings shared with the deal team, with a call to walk through them, then the final report.
Timelines are set by your deal calendar. I scope the depth of the review to the time available and say clearly in the report what wasn’t examined.
Technical due diligence for acquisition vs investment
For a growth investment, the focus is on whether the technology and team can deliver the plan the money is funding, and how much of the raise will go to fixing the platform rather than building new things.
For an acquisition, I add integration questions: identity and billing systems, data migration, overlap with your existing platforms, and which people you must keep. Integration costs are a common place for acquisition models to be optimistic.
For technical due diligence on SaaS, I look closely at tenant isolation, how billing data reconciles with reported revenue, infrastructure cost per customer, and how much of the product is configured per customer rather than shared.
Independence
A diligence report is only useful if it isn’t trying to sell you something. Ask any provider whether they plan to pitch for the post-deal remediation work, and whether they have any relationship with the target. Both should be disclosed before work starts.
If you do want help after the close, that’s a separate conversation: interim CTO cover through integration, or fractional CTO support for a portfolio company that needs senior technical leadership.
More detail
The full scope of what I review, for founders as well as buyers, is on the technical due diligence service page. If you want to see the questions a target should expect, my technical due diligence checklist lists them.
Questions
What does technical due diligence for investors cover?
It assesses the target’s code quality, architecture, scalability, security, infrastructure costs, engineering team and key-person risk, and IP and licensing. The output is a risk register and executive summary that translate technical findings into costs, timelines and deal implications.
How long does technical due diligence take?
It depends on the size of the target and the depth required. A focused review of a single SaaS product fits within a typical deal timetable. I agree scope with the deal team up front and state clearly in the report anything that wasn’t examined.
Will the target company see the report?
That’s your decision. The report is written for the investor or acquirer. Some buyers share findings with the target to agree a remediation plan; others keep it internal. Draft findings go to you first.
Do you need full access to the source code?
Read access to the code is what makes the review reliable, so I ask for it. Where the target is cautious, supervised or clean-room access works. A review based only on interviews and documents is possible, and the report says so plainly.
Looking at a deal with a technology risk?
Send me the target’s profile and your timeline. I’ll tell you what a review can cover in the time you have and what it will tell you.
GMT+2 · Full EU overlap · US East mornings