Technical due diligence before an investment: how to prepare

When talks with an investor reach the technical review, teams often learn more about their own code than they wanted to. Keys in the repository history, one person with production access, backups nobody has ever restored from. Usually none of these kills a deal on its own. What kills it is that they surface unexpectedly and look like things the team didn’t know about.

What they look at

How deep the review goes depends on stage and size of the round, but the topics are almost always the same.

Architecture. What the system is made of, how the parts connect, what happens if load grows several times over. Nobody expects perfection at an early stage. They expect understanding: where the bottlenecks are and what you’ll do about them.

Code. Whether it’s readable, whether the important things are tested, meaning money, permissions and data, and how review and releases work. If a significant share of the code was written with AI, the question will be simple: who on the team understands how it works, and can they change it?

Security. Where secrets are kept, how sign-in and permissions work, whether dependencies get updated, who has access to production and the database.

Infrastructure and operations. How changes get deployed, whether there’s monitoring and alerting, whether there are backups and whether restore has been tested, what happened in recent outages.

Data. What personal data you store, where it physically lives, who can see it, and whether that complies with the laws of the countries your users are in.

Ownership of the code. Whether the company owns its code: are agreements in place with contractors and former employees, what licenses do your libraries carry, and are any of them the kind that oblige you to open your own code.

Team and dependencies. What happens if one key developer leaves. How much the product depends on outside services, and what it would cost to move away from each.

Red flags

Things that show up often and look bad:

• secrets and passwords in the repository, including old commits;
• production accessed from personal laptops, shared accounts;
• backups that have never been restored;
• no separate environment for testing, changes go straight to users;
• no tests on payments or permissions;
• code nobody on the team can explain;
• unclear ownership of code written by a contractor;
• infrastructure or third-party API costs growing faster than revenue, with nobody knowing why.

What to prepare

The good news: most of the preparation is documents, not rewriting code.

• A one- or two-page architecture overview and a diagram: components, data, external services.
• Instructions a new developer can follow to run the project locally.
• A list of external services, what each one does and roughly what it costs.
• A data map: what personal data, where it lives, who has access.
• A list of people and roles with production access.
• A description of how releases and outage recovery work, plus a log of major incidents.
• IP assignment agreements and a list of dependency licenses.
• An honest, prioritized list of technical debt.

That last item matters more than it looks. Debt the team named itself and has a plan for is a normal part of an early company. The same debt discovered by a reviewer looks like a sign the team can’t see its own product.

When to start

A few months before the round, not the week the question list arrives. Some flags take a day to close: rotate leaked keys and remove them from the repository, shut down shared accounts, restore the database from a backup and write down how long it took. Others take weeks. Either way, the work pays off even without an investor: a product that’s ready to be reviewed is also easier to live with.

SUBXCAT runs this kind of audit ahead of time and helps close what it finds before someone else finds it.