A technology due diligence report has one job: tell the investment committee what the technical risks are, how much they matter to the thesis, and what they will cost to fix. Everything below — the codebase read, the infrastructure assessment, the team evaluation — exists to support those three answers. A report a partner who doesn't write code can't act on has failed at its actual job.
We assess six dimensions. For each, the inputs are what we need access to, and the finding is the investment-relevant conclusion we deliver. We publish the framework openly; the proprietary scoring thresholds and tooling stay with the engagement.
The six dimensions
- 01
Codebase quality & maintainability
Inputs: Read access to the repositories, commit history, test coverage, CI/CD configuration.
Finding: Whether the code can be safely changed and extended, or whether velocity will stall under technical debt — and what it would cost to get it to investable shape.
- 02
Infrastructure & scalability
Inputs: Architecture diagrams, cloud configuration, current load and headroom, cost data.
Finding: Whether the system can absorb the growth the thesis assumes, and where the cost or re-architecture cliffs sit on that path.
- 03
Security posture
Inputs: Access controls, secrets handling, dependency and vulnerability scans, incident history, compliance status.
Finding: The material security and compliance exposures that affect valuation or carry remediation cost — separated from the noise.
- 04
Technical debt & architecture
Inputs: Module structure, coupling, key abstractions, known workarounds, the parts of the system the team avoids touching.
Finding: Where debt is load-bearing versus cosmetic, and which items must be addressed before the roadmap is achievable.
- 05
AI readiness & differentiation
Inputs: Model architecture, proprietary data assets, evaluation discipline, deployment maturity, third-party dependencies.
Finding: Whether the AI is a defensible differentiator or a thin wrapper — and whether the data moat the deck claims actually exists.
- 06
Engineering team & key-person risk
Inputs: Org structure, tenure, ownership map, documentation depth, hiring pipeline.
Finding: Whether the team can deliver the roadmap, and where critical knowledge concentrated in one or two people threatens continuity post-close.
The output: investment-grade findings
The six dimensions feed one deliverable. Each finding is written for the investment committee, not the CTO, and carries three things:
Risk
What specifically is wrong or fragile, in plain terms.
Materiality
How much it matters to the thesis — deal-breaker, priced-in, or noise.
Remediation cost
A quantified estimate to fix it, in money and time, to put in the model.
The depth scales with the deal: a focused red-flag review for a smaller add-on, a comprehensive assessment with full remediation costing for a platform acquisition. The constant is independence — the value of diligence is an honest read on a deal everyone around the table is motivated to close.
If you're earlier in the process and still selecting a provider, our companion guide on how to choose a technology due diligence firm covers the questions to ask and the red flags to avoid.