Technical due diligence: what they actually look at.

When an investor or acquirer sends in a technical reviewer, they are answering one question: if we put money in, what breaks, what does it cost to fix, and how long is this team going to be paying for decisions made three years ago. Everything below rolls up into that.

Ownership and licensing

The first thing checked, and the one that most often stops a deal outright.

• Every contractor and agency who touched the code has a signed agreement assigning intellectual property to the company. Not an invoice. An assignment.
• Founders who wrote code while employed elsewhere have clean ownership of it.
• Open-source licences in use are compatible with a commercial product. Copyleft licences in a product you intend to sell are a genuine problem.
• Domains, cloud accounts, app store listings and repositories are owned by the company, not by a personal account belonging to a former developer.

Architecture and scale

• Does the design support ten times the current load without a rebuild, and what specifically would break first?
• Is customer data properly separated? Multi-tenant mistakes are hard to unpick later.
• How many parts of the system can only be changed by one person?
• What is running on end-of-life software or an unsupported framework version?
• Where is the single point of failure, and what happens when it fails?

Code quality, judged commercially

Nobody expects perfection at your stage. Reviewers look for the signals that predict future cost: automated tests around the parts that matter, a deployment that does not require a specific person, dependencies that have been updated this year, and a codebase a new engineer can be productive in within a fortnight.

Security and privacy

• Access control: who can reach production, and is it removed when people leave?
• Secrets management: no credentials in the code repository, and the ones that leaked have been rotated.
• Data handling: what personal information you hold, where it lives, and whether it crosses borders.
• Australian Privacy Act obligations, and the notifiable data breach scheme if you hold personal information.
• Backups that have been restored in a test, not backups that merely exist.
• A written incident response plan, even a short one.

Team and key-person risk

Reviewers will ask who wrote most of the system, whether that person is still here, and what happens if they leave. They will look at how much knowledge is documented rather than remembered. A strong product with one irreplaceable engineer is discounted, and correctly so.

Cost and vendor exposure

• Cloud spend per customer, and whether it improves or worsens as you grow.
• Contracts that auto-renew, and anything with an exit fee.
• Dependence on a single vendor with no realistic migration path.
• Licences priced per seat that will bite at the scale in your forecast.

How to prepare, in order

1. 1Collect every contractor and agency agreement and confirm IP assignment in each one. Fix the gaps now.
2. 2Write a one-page architecture summary a non-engineer can follow.
3. 3List your known technical debt yourself, with an estimate to fix each item. Volunteering the list reads as competence; having it found reads as risk.
4. 4Test a restore from backup and write down the date you did it.
5. 5Remove access for everyone who has left.
6. 6Have someone independent run the review before the investor does.

That last step is the whole point. Findings you raise yourself, with a plan attached, are diligence going well. The same findings surfaced by the buyer become price negotiations. If you are weighing whether an independent review is worth it, the pricing article covers what one costs.