What technical due diligence really checks before an acquisition or round
Buyers and later-stage investors look past the demo to your code ownership, licenses, security record and cloud bill. Here is what they examine and how to prepare.
The demo gets a company into a deal. Technical due diligence decides whether the deal closes on the terms everyone shook hands on.
Technical diligence is the review an acquirer or later-stage investor runs on your engineering organization, codebase and infrastructure before money changes hands. Its scope varies with the size of the deal. A small extension round may involve a single call with the CTO. An acquisition can mean weeks of document requests, automated code scans and interviews with much of the engineering team.
The goal from the other side of the table is simple: find anything that would cost money, time or legal exposure after closing, and either price it in or make fixing it a condition of the deal.
Ownership of the code itself
The first question is whether the company actually owns what it sells. Reviewers check that every founder, employee and contractor who wrote code signed an agreement assigning their intellectual property to the company. Gaps are common at startups that used freelancers early or started building before incorporation, and they are among the issues most likely to hold up a closing.
Open-source licensing is the second half of the ownership question. Nearly all modern software is built on open-source components, which is normal and expected. The concern is specific licenses. Permissive licenses generally allow commercial use with attribution. Copyleft licenses can require you to release source code under certain conditions, and some are written to reach software offered to users over a network. Buyers often run a software composition scan that lists every dependency and its license, so run one yourself first.
Architecture, debt and scale
Reviewers want to understand how the system is built and whether it can carry the growth plan in the deal model. Expect requests for an architecture diagram, a description of the deployment process and an honest account of known technical debt.
Debt is not disqualifying. Every startup has it. What worries a buyer is debt nobody has written down: a core service only one person understands, a database that has never been restored from backup, or a dependency that is years past end of life. A documented list with rough remediation estimates reads as a mature team. A list the buyer assembles on its own reads as a surprise, and surprises get priced.
Key-person risk sits in this section too. If critical systems depend on a single engineer, an acquirer may ask for retention arrangements or treat the gap as a cost to be covered after closing.
Security and privacy record
Expect questions about how access to production is controlled, whether multifactor authentication is enforced, how secrets are stored and how vulnerabilities are tracked and patched. Reviewers will ask for recent penetration test reports, any security attestation reports or certifications, and a history of incidents.
Be candid about incidents. A past breach that was handled well, documented and disclosed where required is manageable. One that surfaces from a third party during diligence damages trust in everything else you have said.
Privacy gets similar scrutiny: what personal data you collect, where it is stored, what your privacy policy told users, and whether your actual practices match those promises. Data collected under one set of commitments cannot always be put to a buyer's different purposes.
Costs and the cloud bill
Infrastructure spend is increasingly part of the review. A buyer will look at how hosting costs scale with usage and whether gross margin holds up as customers grow. A cloud bill that rises faster than revenue, or one propped up by promotional credits about to expire, changes the economics of the deal.
Third-party software and API contracts matter as well. Reviewers check whether key vendor agreements can be assigned to a new owner, whether change-of-control clauses are triggered, and whether the product depends on a single supplier that could change its pricing or terms.
How to prepare before anyone asks
Run your own diligence well before you expect to need it. Most fixes are cheap when done early and expensive when done under a closing deadline. Confirm IP assignment paperwork for every current and former contributor, and close gaps with signed confirmatory assignments while people are still easy to reach.
Generate a dependency and license inventory, often called a software bill of materials, and resolve anything your counsel flags.
Write down your architecture, your deployment process, your known debt and your incident history, and keep them current in one place you could share in a data room.
Make sure more than one person can deploy, restore from backup and access every critical system. Then test that claim with an actual restore.
Finally, decide in advance who on your team speaks to reviewers, and brief them. Diligence interviews reward engineers who answer precisely and say plainly when they do not know something.
This is general information, not legal advice. Speak to a qualified attorney in your jurisdiction before acting on any of it.
