Templates

Technical due diligence checklist for software investments

For investors and acquirers of software companies: what to review, what to ask for in the data room, how to rate each risk, and how to turn findings into a 100-day plan.

By the Ryz Labs team · Updated October 2026

Technical due diligence answers three questions for an investor or acquirer: what could break, what it would cost to fix, and whether the team and technology can support the growth plan in the investment thesis. A complete review covers architecture and scalability, code quality and technical debt, security, data, infrastructure and operations, the engineering team and key-person risk, third-party and open-source dependencies, and the product roadmap. Each finding gets a severity, an estimated cost to fix and a decision: price it, fix it in the first 100 days, or accept it.

Technical due diligence checklist

1. Review areas and what to check

Architecture and scalability

☐ Architecture diagram that matches what is actually deployed
☐ Main components, data flows and external dependencies
☐ What breaks first at the growth the thesis assumes (2x, 5x users or data)
☐ Single points of failure and how they are mitigated

Code quality and technical debt

☐ Language and framework versions; anything past end of support
☐ Automated test coverage on critical paths and how often tests run
☐ Static analysis results: complexity hotspots, duplication, known vulnerabilities
☐ Areas engineers avoid changing, and why
☐ Technical debt the team already tracks, with their own estimates

Security

☐ Recent penetration test results and what was fixed
☐ Authentication, authorization and secrets management
☐ Dependency vulnerability scanning and patch cadence
☐ Security incidents in the last three years and how they were handled
☐ Compliance reports and certifications claimed (SOC 2, ISO 27001, HIPAA, PCI DSS), with evidence

Data

☐ Where customer data lives, who can access it and how access is logged
☐ Backups and tested restores
☐ Data retention and deletion practices against privacy laws that apply
☐ Data quality issues that affect reporting or product features

Infrastructure and operations

☐ Hosting, cloud accounts and who controls them
☐ CI/CD: how code reaches production and how often
☐ Monitoring, alerting, on-call and incident history
☐ Cloud cost trend and the biggest cost drivers

Team and process

☐ Org chart, tenure and who knows the critical systems
☐ Key-person risk: systems only one person understands
☐ Use of outside engineering partners and what they own
☐ How work is planned, reviewed and released

Intellectual property and open source

☐ Company owns its source code, with no unresolved ownership claims
☐ Open-source licenses in use and any copyleft obligations triggered
☐ Third-party components or APIs the product cannot run without

AI and data products (if any)

☐ Which features use AI, which models and providers, and where data is sent
☐ How AI quality is measured and monitored
☐ Cost per request and dependence on a single provider

2. Data room request list

Item	Why	Received
Architecture diagrams and system inventory	Baseline for the review	[Yes / No]
Read access to source code repositories	Code quality and IP review	[ ]
Last three penetration tests and remediation status	Security posture	[ ]
Incident reports for the last 24 months	Reliability and operations	[ ]
Cloud bills for the last 12 months	Cost trend and drivers	[ ]
Engineering org chart with tenure and roles	Team and key-person risk	[ ]
Open-source license scan or software bill of materials	IP and license risk	[ ]
Product and technical roadmap	Fit with the investment thesis	[ ]

3. Findings and risk rating

Finding	Area	Severity (high / medium / low)	Likelihood	Estimated cost to fix	Time to fix	Recommendation (price in / 100-day plan / accept)
[Core service on a framework past end of support]	[Code]	[High]	[Certain]	[Team x months x monthly cost]	[Months]	[100-day plan]
[Finding]	[Area]	[ ]	[ ]	[ ]	[ ]	[ ]

Use this template

How to use this due diligence checklist

Start from the investment thesis. List the growth, product and cost assumptions the technology must support, and review against those, not against an ideal system.
Send the data room request list on day one. Access to code and documents is usually the longest delay.
Interview the CTO, two or three senior engineers and the person who runs operations. Verify what you hear in the code, the deployment pipeline and the incident history.
Work through the review areas and log every finding in the risk register with severity and likelihood.
Estimate cost to fix each finding as team size x months x monthly cost per engineer. Use ranges, and state your assumptions.
Write a short report: executive summary, top risks with cost to fix, items to price into the deal, and a draft 100-day technology plan.

Example: a rated finding

Field	Example
Finding	Billing and reporting run on one database with no read replica; month-end reports slow the product for all customers.
Severity / likelihood	Medium / certain at the user growth in the thesis
Cost to fix	Two senior engineers for about three months to split reporting onto a replica or warehouse (2 x 3 x monthly cost per engineer)
Recommendation	100-day plan; not a reason to change price

Common technical due diligence mistakes

Relying on management presentations. Verify claims in the code, pipeline and incident history.
Reviewing against perfection. Every system has debt. What matters is the debt that blocks the thesis.
Findings without costs. A list of problems does not help a deal team. Attach a cost range and time to every major finding.
Ignoring key-person risk. A system only its author understands is a risk the moment the deal closes.
Skipping open-source license review. Copyleft obligations can matter for products distributed to customers.
No 100-day plan. The review should end with the first steps after closing, including who will do the work.

Need engineers for the 100-day plan?

Ryz staffs the work due diligence uncovers, for investors and their portfolio companies: modernization, security fixes, data platforms, AI features and key-person backfills. Senior engineers join the portfolio company's team, reporting to its leads, on US business hours including New York hours, and AI pod teams build in the company's cloud and repos. Only the top 1% of the tens of thousands of engineers we interview make it. Typical cost is $7,000 to $15,000 per engineer per month, which keeps cost-to-fix estimates concrete. Talk to us to scope the team.

FAQ

What is technical due diligence?

A review of a software company's technology, engineering team and processes before an investment or acquisition. It identifies risks to the investment thesis, estimates the cost to fix them and recommends what to price in, fix after closing or accept.

What does a technical due diligence checklist include?

Architecture and scalability, code quality and technical debt, security, data handling, infrastructure and operations, the engineering team and key-person risk, intellectual property and open-source licenses, and, increasingly, how the company uses AI and model providers.

How long does technical due diligence take?

Often one to three weeks depending on deal size and complexity. The biggest variable is how quickly the data room and code access are provided, so request them on day one.

Who should perform technical due diligence?

Senior, independent engineers who have built and run systems like the target's: a fractional CTO, an experienced engineering leader or a specialist firm. They should read code and pipelines, not just interview management.

What happens after technical due diligence?

Findings feed the deal terms and a 100-day technology plan. The plan names the top fixes, owners, budget and the engineers who will do the work, and it is reviewed with the new leadership team after closing.

Questions we didn't answer? Email info@ryzlabs.com.