When you buy or invest in a business whose product is software, the accounts tell you what it has earned. They do not tell you whether the product can keep earning without a rewrite, whether the people who understand it are staying, or whether the code you are paying for is actually owned by the company selling it.
That is what technical due diligence is for. Here is what it should cover, in plain terms.
1. Who owns the code
Every contributor, employee or contractor, should have assigned their work to the company. Gaps are common in early-stage businesses, where founders and freelancers wrote the first versions. Check that the code, the domains, the app store accounts and the cloud accounts are all in the company’s name. Our checklist on whether you own your software covers each one.
2. What the code is built from
Modern software is assembled from open-source components, each with a licence. Most licences are harmless for commercial use. A few can impose obligations that matter in a sale. You want a list of what is used and a view on whether anything conflicts with how the product is sold.
3. Who understands it
If one person built most of the product and holds most of the knowledge, the business carries a risk that does not show up on a balance sheet. Ask who could fix a serious problem at short notice, and whether they are staying after the deal. Look for documentation that would let someone new get started.
4. Whether it is safe
Look for evidence, not assurances: how access is controlled, how customer data is protected, when the software’s components were last updated, and whether there have been incidents. A product that holds personal data also brings privacy obligations with it.
5. What it will cost to keep
Every product carries some technical debt: shortcuts that worked then and need paying down later. The question is how much, and where. Is the product built on technology that is still supported? Are hosting costs understood and stable? Is a large rebuild quietly waiting in the plan?
6. Whether it matches the story
The pitch describes the product the seller believes they have. Diligence checks the product they actually have: that the features exist, that the architecture can carry the growth in the plan, and that “AI-powered” means something real.
What good diligence gives you
Not a long list of problems. Every product has problems. You want each finding with what it means for the deal, what it would cost to fix, and who would fix it, so it can inform the price, the terms or the plan for the first months after completion.
That is the difference between a technical report and a decision document. You should be able to read the first page and know whether to proceed.