Technical due diligence, written for the people signing the cheque.
Before a round closes or an acquisition completes, someone has to answer whether the technology can carry the plan the deal is priced on. We review the architecture, the codebase, the infrastructure and the team, then hand over a report that states the risks, ranks them, and puts a number on fixing each one.
When funds call us
- The team is impressive and we cannot independently verify what they have built.
- The plan assumes ten times the load. Nothing in the current system suggests it will get there.
- One engineer appears to understand the whole platform, and we need to know how bad that is.
What the review covers
Architecture and scalability
Whether the system as built can reach the numbers in the model, and what has to be rebuilt if it cannot. We separate what breaks at 10× from what breaks at 100× — those are very different price tags.
Code quality and technical debt
Where the debt is concentrated and what it costs per shipped feature. Debt in a stable, rarely-touched module is not a finding; debt on the critical path is. We report the difference rather than a raw score.
Security and compliance exposure
Authentication, secret handling, data flows, dependency risk and third-party exposure, assessed against the obligations the business actually carries in the markets it sells into.
Team, ownership and key-person risk
Who knows what, how much of the system has exactly one person who understands it, and how quickly a replacement could get productive. Usually the finding with the largest effect on valuation.
Delivery capability
How long a change takes from decision to production, and how often it goes wrong. A team that ships weekly and a team that ships quarterly present the same roadmap very differently.
Remediation cost and sequence
Every material finding gets an estimate in engineering months and a position in a sequence, so the number can go into the model instead of into a footnote.
What you receive
- A written report structured for an investment committee, not for engineers
- Findings ranked by impact on the thesis, each with an estimated remediation cost
- A red-flag summary you can read in five minutes
- An architecture and dependency map of the system as it actually is
- A call with your team and, if useful, with the target's engineers
Related work
Infrastructure Cluster
A private self-hosted infrastructure cluster built on Proxmox, OpenTofu, Terragrunt, Ansible, K3s, GitOps, dedicated runner VMs, and a separate AI control plane for delivery experiments and internal operations.
View projectAvtoReyestr
A full-stack data product for exploring the Ukrainian vehicle registry through search, analytics, dashboards, authenticated user flows, public API documentation, and an operational admin surface.
View projectQuestions we hear from funds
Diligence coming up?
Request a diligence scopeTypically one to three weeks depending on system size and access. We can usually start within five to seven business days, and we will say up front if your timeline is not realistic rather than deliver a thin review on schedule.
Read access to the repositories, a walkthrough of the infrastructure, and interviews with two or three engineers. We can work from a narrower scope, and the report states plainly which conclusions were limited by access.
Always, and we are equally happy to sign the target's. Access is scoped to what the review requires and revoked when it ends.
We disclose any prior relationship before the engagement starts, and we do not pitch remediation work to a company we have just assessed for you. A diligence report is only useful if the reviewer had nothing to sell.
Then that is the report. A clean review with evidence behind it is a legitimate and useful outcome, and we would rather deliver one than manufacture concerns to justify the fee.