Technical Due Diligence: A Checklist for Investors and Acquirers
Technical due diligence answers one question before you sign: can this technology carry the plan you are paying for? Here is what to check, and what should change the deal.
Can this technology carry the plan you are paying for?
Technical due diligence is an independent review of a company's software, infrastructure and engineering team before an investment or acquisition. It checks whether the product can scale to the plan in the deck, what it will cost to fix what is broken, and which risks belong in the price or the contract. A focused review usually takes two to three weeks and ends with a report that rates every finding by severity and cost to fix.
The review does not grade code style. It answers business questions: how much of next year's budget goes to rework, whether the product depends on one engineer, and whether the company owns what it sells.
When technical due diligence happens
- Venture rounds from Series A onward, when the round funds scale the current system may not survive.
- Acquisitions and private equity buyouts, where the buyer inherits the code, the cloud bill and the security history.
- Carve-outs and mergers, where two systems must be separated or joined.
- Sell-side readiness, when founders run the review on themselves a quarter before fundraising so nothing surprises the buyer.
Buyers commission most reviews. The sell-side version is cheaper in the long run: problems found early can be fixed before they turn into a price discussion.
The technical due diligence checklist
- Architecture and scalability. A current diagram, the parts that break first at ten times the load, single points of failure, and how the system was load-tested.
- Code quality and tests. Test coverage on the paths that move money or data, the age of frameworks and libraries, and how long a typical change takes from commit to production.
- Security and compliance. Secrets management, access control, the last penetration test, open findings, and evidence for SOC 2, ISO 27001, HIPAA or PCI DSS if customers require them.
- Intellectual property. IP assignment from every employee and contractor, open-source licences (copyleft code inside a proprietary product is a classic finding), and third-party code with unclear ownership.
- Infrastructure and cost. Cloud spend against revenue over the last 12 months, environments, backups and a tested restore, disaster recovery.
- Data. Where personal data lives, retention, consent, data residency and the quality of the data the business plan depends on.
- Team and process. Who knows each critical system, documentation and architecture decision records, on-call, release frequency and incident history.
- Vendor dependencies. Critical third-party services, their contracts, and what leaving each one would cost.
- Roadmap feasibility. Whether the next 18 months of the roadmap fit the architecture and the team, or need a rebuild first.
Red flags that change a deal
Most findings are routine and go into a 100-day plan. These are the ones that move the price, the structure or the decision:
- One engineer is the only person who can deploy or fix the core system.
- Contractor code without signed IP assignment.
- Copyleft-licensed code linked into the commercial product.
- Production secrets in the code repository.
- No restore of the backups has ever been tested.
- Cloud cost growing faster than revenue, with no explanation.
- A core framework past end of support, so security patches have stopped.
- A roadmap that quietly assumes a rewrite nobody has budgeted.
How a two-to-three-week review runs
Week 1: documents and interviews. Architecture diagrams, security policies, the cloud bill, the org chart and conversations with the CTO and the engineers who own the critical systems.
Week 2: hands-on access. Read-only access to repositories, CI/CD and cloud accounts; automated scans for dependencies, licences and secrets; a walk through the riskiest code paths.
Week 3: the report. Findings rated by severity, each with an estimated cost and time to fix, plus a short list of items that should affect price or terms.
What the report should give you
A useful report is short at the top and detailed underneath. The first page should state whether the technology can support the plan, the three to five findings that matter, and the total remediation cost. Behind it: every finding with evidence, severity, effort, and the owner who would fix it.
Remediation cost is the number buyers use most. It feeds a price adjustment, an escrow, a condition before closing, or the first 100 days of the post-deal plan.
How founders can prepare
- Keep an up-to-date architecture diagram and a folder of architecture decision records, so reviewers read the reasoning instead of guessing it.
- Run a dependency and licence scan, and fix the obvious items.
- Collect IP assignments from everyone who has written code, including past contractors.
- Move secrets out of repositories and rotate them.
- Test a backup restore and write down how long it took.
- Make sure at least two people can deploy and operate each critical system.
If you want an outside view before investors arrive, our software architecture consulting team runs this review as a two-to-three-week architecture assessment.
We run technical assessments for investors and for founders preparing to raise. See software architecture consulting, or bring in a fractional CTO to own the fixes after the deal.
Recent blog posts
With staff augmentation you rent engineers and run them yourself. With managed services a vendor owns the result. The right choice depends on who should own the work, and the knowledge, a year from now.
