Technical Due Diligence

What this answers

Not “is the code good.” Code quality is a proxy, and a weak one. The questions that actually move a deal are:

• Can this architecture support the growth in the plan, or does the plan assume a rewrite nobody has priced?
• What is the real technical debt position, in cost and time rather than adjectives?
• Does the engineering organisation have key-person risk, and what happens if that person leaves post-close?
• Is the release and quality system capable of supporting enterprise or regulated customers?
• Where are the security, compliance and data-handling exposures that become the acquirer's problem?
• If AI features are part of the story, are they production systems or demos?
• What would need to be spent, and over what horizon, to make the technology match the thesis?

Methodology

Days 1–2 — Framing. I start from your investment thesis, not from the repo. What has to be true technically for this deal to work? Those become the questions the assessment is built to answer.

Days 3–6 — Evidence gathering. Repository and architecture review, CI/CD and incident history, dependency and infrastructure posture, security and compliance artefacts, test and release process, and the engineering org structure. History is more honest than documentation, so I weight it accordingly.

Days 5–8 — Interviews. Structured sessions with the CTO or engineering lead, one or two senior engineers, and where relevant product and QA leadership. The sessions are designed to surface what the artefacts cannot: what the team is worried about.

Days 8–10 — Report and readout. Written findings plus a live session where I answer questions and stress-test my own conclusions in front of you.

What you receive

• An executive summary written for an investment committee, with a clear risk rating and the two or three findings that actually matter
• Architecture assessment: scalability ceilings, coupling, single points of failure, and what the next 10× costs
• A technical debt register with remediation effort estimated in engineer-months
• Engineering organisation and key-person risk assessment
• Quality, release and operational maturity rating against enterprise/regulated expectations
• Security, compliance and data-handling observations at a diligence level
• AI systems assessment where AI features are material to the thesis
• A prioritised post-close technical plan — what the first two quarters should fund
• An explicit list of what I could not verify, and why

Turnaround

Standard engagement is 10 business days from data-room access. An accelerated 5-day version is available for competitive processes, with a narrower scope stated up front rather than the same scope rushed. Diligence engagements can typically begin within 2 business days of instruction.

Scope limitations — stated plainly

A diligence report is only useful if its boundaries are honest.

• This is technical diligence only. It is not legal, financial, commercial or IP diligence, and it does not substitute for them.
• It is not a security audit or penetration test. I will flag exposures at a diligence level and recommend a specialist assessment where warranted.
• It is not a code audit line by line. I assess structure, history and organisational capability — the things that predict future cost.
• Findings are bounded by the access granted. Anything I could not verify is listed as unverified rather than assumed.
• I do not write conclusions to order. If the technology supports the thesis, the report says so; if it does not, it says that too.

Independence

I take no fee contingent on a deal closing, and I hold no position in the target. Where a post-close engagement is later discussed, that is a separate commercial conversation initiated after the report is delivered — never bundled, and never a reason to shade a finding.

Investment

Fixed fee, agreed before instruction, scaled to company size and scope. Quoted within one business day of an initial scoping call. No hourly billing.