Technical due diligence: what an investor looks at
How to assess a startup’s product, code, team and risks in a limited window before an investment or a deal — and which conclusions matter most.
When an investor or a buyer is about to put money into a product, they want an independent assessment of its technical side. Technical due diligence is not a hunt for bugs and not an audit for its own sake. It answers a specific question: how technically sound is what you’re being offered, what are the risks, and what do they cost.
In a limited window — usually from a few days to a couple of weeks — you have to form a reliable picture. Below is what I assess first.
Architecture and the capacity to grow
The main question is whether the system will withstand the growth the business plan assumes. A solution that works at the current load can prove to be a dead end at ten times the scale. What matters is understanding not only the present state but also which changes will be required and what they will cost.
Technical debt and its real cost
Every project carries technical debt, and on its own it is not a verdict. What matters is its volume and how it affects the speed of change. I assess what it will cost to put the system in order and whether the product can be developed without rewriting it entirely.
The team
Code is written by people, and dependence on them is a risk in itself. Who actually understands the system as a whole? What happens if a key engineer leaves? It often turns out that critical knowledge rests on one or two people, and that matters more than the quality of individual modules.
Processes and infrastructure
How deployment, testing, monitoring, backups and security are set up. The absence of basic processes is a signal that the product is held together by manual effort and heroics, and such arrangements survive growth and team changes poorly.
Match with what’s claimed
Separately, I check whether what’s being sold has actually been built. A gap between the pitch and the real state of the system is a common and expensive finding.
What the conclusion looks like
The result is not a verdict of “good code or bad,” but a clear statement: whether to invest, what to watch for, what needs fixing and on what timeline, and what it will cost. The decision stays with the investor — my job is to give them a reliable basis for it.
Common red flags
The usual warning signs are: critical knowledge concentrated in a single person; a complete absence of tests and automation; an architecture not built for the stated load; and a visible gap between what is shown and what actually exists.
In summary
The goal of technical due diligence is not to find perfect code, which doesn’t exist, but to give the investor a clear understanding of the risks and the upside, so the deal is made deliberately rather than on trust in a presentation.