Technical due diligence: ten questions to ask before you invest
Investors are good at reading financials and markets. The codebase is usually a black box until something goes wrong after the round closes. Ten questions that open the box without needing to read the code yourself.
In a typical deal, the product gets a demo, the market gets a model and the team gets interviews. The software that has to carry the next two years of growth often gets a single question — “is the tech solid?” — and a confident yes. Technical due diligence exists because that yes is sincere and frequently wrong, not out of dishonesty but because founders rarely see their own system from the outside.
The questions below do not require reading code. They are designed to be asked of the founding team and checked against evidence: a repository, a dashboard, a bill. Vague or contradictory answers are the finding.
Ownership and control
- Who owns the code, the domain, the cloud accounts and the app store listings — the company, or a founder or contractor personally?
- Could the company deploy the product tomorrow if its two most senior engineers left?
These sound administrative and are the ones most often answered badly. A repository on a freelancer's personal account, or production running under a founder's credit card, is a negotiation point before the round and a crisis after it.
Delivery
- How often does code reach production, and how — by a pipeline, or by someone running commands?
- When a release breaks something, how is it rolled back, and when did that last happen?
- Is there a staging environment that resembles production closely enough to trust?
Release frequency is one of the most honest signals available. A team that ships small changes several times a week can usually change direction cheaply. A team that ships once a month in a nervous all-day event will spend a disproportionate share of the new budget on keeping things from breaking.
Reliability and data
- Are there backups of production data, and has anyone ever restored one?
- What happened during the last outage, and how did the team find out about it?
- Which personal or regulated data does the product store, and who can access it?
Cost, scale and the plan
- What does the infrastructure cost per month, and how does that number move as users grow?
- Which parts of the system have to be rebuilt to deliver the roadmap this round is funding?
Many products have perfectly healthy unit economics on paper and an infrastructure bill that grows faster than revenue in practice — especially where large language models or video are involved. Asking for the last six monthly invoices next to the user numbers for the same months takes five minutes and often changes the model.
Every system also has parts that were built to get to the first customers and will not survive the next hundred. That is normal and not a red flag. The red flag is a roadmap that does not budget for it, or a team that has not noticed.
Reading the answers
Few companies at seed or Series A answer all ten well, and they should not be expected to. What matters is whether the team knows where its weak points are and has a credible, costed plan for them. A founder who says “our deployment is manual and here is when we fix it” is a better bet than one who says everything is fine. An independent review exists to tell those two apart before the money moves, not after.