What Technical Due Diligence Actually Checks

A polished demo tells you what a product does on a good day. Due diligence tells you what it costs to keep it running, and what you are actually buying.

When I assess a tech asset for an investor, buyer, or operator, I am not grading the UI. I am answering one question: how much risk is hidden in this system, and how much will it cost to remove it?

The areas that matter

• Architecture. Is the system designed to scale, or held together by manual steps and one person's memory? Coupling, data ownership, and failure modes are where future cost lives.
• Code and delivery. Is there a real CI/CD pipeline, or do deploys depend on a single laptop? Test coverage and release history reveal whether the team can ship safely.
• Security and compliance. Authentication, secret management, dependency CVEs, and data handling (GDPR, Law 25 in Québec) are the items that turn into liabilities post-close.
• Cloud cost. Spend that grows faster than usage is a margin problem disguised as an infrastructure line.
• Key-person risk. If the only person who understands the core system leaves, what breaks? Documentation and knowledge transfer are part of the valuation, not an afterthought.

What a good report gives you

Not a vague "the code is fine." A prioritized list: critical issues that should affect the price or the deal, high-risk items to fix in the first 90 days, and a realistic estimate of the work to bring the asset to a defensible standard.

Technology should make a deal easier to underwrite — not a black box you hope is fine.