How technology due diligence works in private markets

In most private-market deals involving a software company, the technology is the asset. The code, the data, the platform, and the people who keep it running are what the money buys. Yet technology often gets less scrutiny than the accounts.

Financial due diligence tells you what the company earned. Legal due diligence tells you what it owns on paper. Technology due diligence tells you whether the asset itself can carry the plan — and what it will cost to keep it doing so.

Here is how the work runs when it is done well.

When investors use it

Before a term sheet. A short screening review. Does the technology broadly support the story being sold? Are there problems big enough to change the price or stop the deal?
Before completion. The full review. Code, architecture, security, intellectual property, AI claims, team, and running costs, examined against the investment case.
Inside the portfolio. When a company's technology stops matching its reporting — delivery slows, costs climb, a key engineer leaves — an independent check tells the board what is actually happening.
Before an exit. Sellers who run the review on themselves first go into a sale knowing what a buyer will find, with time to fix it.

What gets examined

The review is not an audit of code style. It is a check on whether the technology supports the commercial story. In practice that means six things:

Code quality and technical debt — how well the software is built, and what the shortcuts will cost to fix.
Security — how data is handled, who can access what, and what a breach would look like.
Intellectual property — whether the company owns the code it depends on: contractor assignments, open-source licence obligations, and the origin of AI-generated code.
AI claims — whether the AI is genuine engineering, useful automation, or a thin layer over a public model.
Team and key-person risk — how much of the system lives in one person's head.
Scalability and cost — whether the platform and the cloud bill can carry the growth plan.

What you receive

A useful report is written for the people making the decision, not for engineers. It should say, in plain English: what is solid, what is fragile, what it costs to fix, and what should happen before or after completion. Risk ratings a deal team can act on. A briefing call where the partners can ask anything.

A full report typically takes two to three weeks. A rapid red-flag review takes five to seven days. Everything runs under NDA.

What it is not

The goal is not to find a perfect company. There are none. Every codebase has debt and every team has gaps. The goal is a priced view of the risk: which problems are normal, which are expensive, and which change the deal.

That is the standard I hold my own work to — technical due diligence for investors who want the technology understood before the money is committed.