Technical due diligence is not an audit of whether your code is elegant. It is an assessment of one question: how much money and time stands between this company and the next stage of its plan? Everything a reviewer looks at is a proxy for that.

Knowing the structure lets you run it on yourself first, which is the entire advantage. Findings discovered internally are engineering tasks. The same findings discovered during a raise are negotiating positions for the other side.

Area 1 — Ownership and licensing

Reviewed first, because nothing else matters if this fails. The reviewer establishes that the company owns what it claims to own: employment and contractor agreements with valid IP assignment for every contributor, a complete dependency inventory with licences, and no copyleft code inside a distributed commercial product.

The finding that hurts: contractors abroad with confidentiality clauses but no assignment. It is common, and remediation means locating former contributors — which cannot be done on a deal timeline.

Area 2 — Architecture and scalability

Not "will it handle a million users" — nobody expects that. The question is whether the plan you presented is achievable on this foundation without a rewrite. Reviewers look for single points of failure, data models that will not survive the next feature, and coupling that makes parallel work impossible.

The finding that hurts: a single-tenant design in a company selling to enterprises. Multi-tenancy retrofitted late is one of the most expensive changes in software.

Area 3 — Security and data protection

Access control model, secret management, encryption at rest and in transit, dependency vulnerabilities, and how personal data is stored, exported and deleted. If you sell in the EU, California, or to regulated buyers, the reviewer maps your actual practice against what your privacy policy promises.

The finding that hurts: production credentials in the repository history. It is trivially detected, unambiguous, and implies everything else was done the same way.

Area 4 — Engineering process

Code review practice, test coverage where it matters, CI/CD, environment parity, and incident history. Reviewers read your issue tracker and your commit history — both are unedited records of how the team actually works, which is why they are more informative than any interview.

The finding that hurts: all commits from one person. It reads as key-person risk regardless of how good that person is.

Area 5 — Team and knowledge distribution

Who understands which part of the system, what happens if any one of them leaves, and whether documentation would let a replacement function. Reviewers frequently ask an engineer to explain a subsystem they did not build. The answer is the assessment.

Area 6 — Operations and cost

Infrastructure cost per customer, and whether it improves or worsens with scale. Monitoring, alerting, backup and recovery — with evidence a restore has been performed. Uptime history, not uptime targets.

The finding that hurts: unit economics that degrade with growth. It converts a growth story into a cost story in one slide.

Run it on yourself

Take one week. For each of the six areas, produce a document answering the questions above, with evidence rather than assurance. You will find three or four gaps. Fix what is fixable in the time available, and write an honest remediation plan with dates for the rest.

Disclosing a known issue with a plan attached is a sign of a well-run company. Having the same issue discovered by a reviewer is a sign of the opposite — and the difference is measured in valuation, not in engineering.

Diligence does not decide whether your technology is good. It decides who has the information advantage in the negotiation that follows.

We run this review as a fixed-price engagement, delivered as a written report with a prioritised remediation plan. Founders typically commission it eight to twelve weeks before a raise — early enough that the findings are still just work.