Software Acquisition Technology Due Diligence Checklist

Financial and legal diligence tell a buyer what a software company has earned and what it has signed. Technology diligence tells the buyer whether the product that produced those numbers can keep producing them after close, at what cost, and with which people. This checklist is organized the way a diligence workstream actually runs: for each area, what evidence to request, what to ask the people who built it, which findings should slow the deal down, and what those findings usually mean for price, structure or the integration plan.

Use it as a starting point, not a script. A five-person vertical SaaS business and a carve-out from a large enterprise need different depth. The point is to make sure no area is skipped by accident.

Download the checklist as a spreadsheet (CSV).

How to use this checklist

Work in three passes. First, request documents and system access before the first management session so conversations are grounded in evidence rather than slides. Second, interview the people who own each area, ideally the engineers and operators rather than only executives. Third, test a sample of claims directly: open the repository, read the incident log, look at the cloud bill.

For every finding, record three things: what you saw, how confident you are, and whether it affects price (a cost to fix), structure (an escrow, indemnity, holdback or earn-out condition) or the plan (work for the first 100 days). Keep unresolved questions, the evidence behind each finding and your confidence level visible rather than dropping them. Technical diligence provides the evidence; counsel and the deal team decide the contractual response.

1. Architecture and product fit

Evidence to request: current architecture diagrams, a list of production services and data stores, the product roadmap for the next four quarters, and any documents describing planned re-platforming.

Questions to ask: Which parts of the system are the hardest to change and why? What would break first if usage doubled? What has the team wanted to rebuild but not had time for? Which customer commitments depend on roadmap items that are not built yet?

Red flags: diagrams that nobody on the engineering team can explain; a roadmap that depends on a rewrite; core business logic living in a single service or database that only one person understands; customer contracts promising features that do not exist.

Deal implications: a needed rewrite is a cost and a timing risk, and should be reflected in price or in the integration budget. Contracted but unbuilt features are a liability that belongs in disclosure schedules and possibly a specific indemnity.

2. Source code and engineering practice

Evidence to request: read access to the main repositories, branch and review policies, CI/CD configuration, test coverage reports if they exist, and a list of the ten most-changed files over the last year.

Questions to ask: How does a change get from a laptop to production? Who can merge without review? How long does a typical release take, and how often do releases roll back? Which parts of the code are people afraid to touch?

Red flags: production deployments done by hand from a developer machine; no code review; secrets committed to repositories; large areas with no automated tests where most incidents originate; a build that only one person can run.

Deal implications: weak delivery practice slows every post-close initiative. It is usually a plan item rather than a price item, but if the product cannot be released safely it becomes a pre-close condition.

3. Intellectual property and open source

Evidence to request: a software bill of materials or dependency manifest, any open source license scan, contributor and contractor agreements with IP assignment clauses, and a list of code obtained from third parties.

Questions to ask: Has anyone outside the company written code that ships in the product? Were all of them under agreements that assign IP to the company? Does the product include any copyleft-licensed components, and how are they used? Has the company ever received a license compliance request?

Red flags: contractors or founders without signed IP assignment; copyleft components linked into distributed software without a compliance review; code copied from a previous employer; no inventory of dependencies at all.

Deal implications: gaps in IP ownership go to the heart of what is being bought. Expect them to be cured before close where possible (signed assignments), otherwise addressed by specific indemnities, escrow or price.

4. Infrastructure, hosting and cost

Evidence to request: twelve months of cloud invoices broken down by service, the list of cloud accounts and who owns them, infrastructure-as-code repositories, and any reserved-capacity or committed-spend agreements.

Questions to ask: What drives the hosting bill, and how does it scale with customers? Which accounts are owned by individuals rather than the company? What commitments run past the expected closing date?

Red flags: hosting costs growing faster than revenue without explanation; production running in an account owned by a founder personally; infrastructure built by hand with no way to recreate it; large committed-spend contracts the buyer will inherit.

Deal implications: hosting cost is part of gross margin, so an unexplained trend affects the valuation model directly. Account ownership must transfer cleanly and should be a closing deliverable.

5. Security posture

Evidence to request: the most recent penetration test and remediation status, any security questionnaires completed for customers, access review records, vulnerability management process, and a list of security incidents in the last three years.

Questions to ask: Who has administrative access to production, and how is it reviewed? How are leavers removed? When was the last time a vulnerability was found by someone outside the company, and how was it handled? What would you tell a customer who asked for evidence of your controls today?

Red flags: shared administrator accounts; former employees with live access; critical findings from a past test still open; no multi-factor authentication on production or code hosting; security answers to customers that the team cannot back up with evidence.

Deal implications: open critical issues are a pre-close or immediate post-close cost. Misstatements to customers in security questionnaires can become contractual exposure and belong in representations and warranties.

6. Data, privacy and compliance

Evidence to request: a data inventory showing what personal data is processed and where, records of processing, data processing agreements with customers and vendors, retention and deletion procedures, and any regulator or customer audit reports.

Questions to ask: Which regions is customer data stored in? Which sub-processors receive it? How is a deletion or access request handled end to end? Which compliance frameworks have customers asked for, and which has the company committed to?

Red flags: personal data copied into analytics or logs without controls; no record of sub-processors; retention described as "we keep everything"; compliance claims in marketing material that are not supported by an audit or a documented control set.

Deal implications: privacy gaps are both a remediation cost and a liability. If the buyer operates under stricter rules than the target, the gap to the buyer's standard is a plan item that should be budgeted.

7. Reliability and operations

Evidence to request: uptime and incident history for at least twelve months, post-incident reviews, on-call arrangements, backup and restore test records, and any service-level commitments in customer contracts.

Questions to ask: What were the three worst incidents and what changed afterward? When was a restore from backup last tested, and how long did it take? Who gets paged at night, and how many people can actually fix production?

Red flags: backups that have never been restored; no incident records at all; one person carrying on-call; service credits paid under SLAs that are not reflected in the financials.

Deal implications: untested recovery is a business continuity risk and should be addressed early in the plan. Recurring SLA breaches affect revenue quality and customer retention assumptions.

8. Team, knowledge and key-person risk

Evidence to request: an organization chart for engineering, product and operations, tenure and location of key people, contractor arrangements, and any documentation or runbooks.

Questions to ask: If a given person left tomorrow, what would stop working? Which knowledge exists only in people's heads? Which contractors are effectively full-time team members?

Red flags: one engineer who is the only person able to deploy, fix or explain a core system; critical work done by an agency with no transition clause; no documentation for systems that generate revenue.

Deal implications: key-person risk is usually handled through retention arrangements, earn-out design and a documentation sprint early in the 100-day plan.

9. Third-party dependencies and contracts

Evidence to request: the list of vendors and APIs the product depends on, their contracts, any change-of-control clauses, and usage-based pricing terms.

Questions to ask: Which vendors could the product not run without? Do any contracts terminate or reprice on a change of control? Are there single points of failure in external services?

Red flags: a critical API on a consumer or personal account; change-of-control termination rights in a key vendor contract; pricing that changes sharply at the volume the buyer plans to reach.

Deal implications: required consents should be obtained before close. Repricing risk belongs in the cost model.

10. Technical debt and the cost to carry

Evidence to request: the backlog of known technical debt, end-of-life components and frameworks, and any estimates the team has made for upgrades.

Questions to ask: Which frameworks, languages or databases are past or near end of support? What has been deferred to hit recent releases? What would the team fix first with an extra quarter?

Red flags: core components on unsupported versions; deferred upgrades that block security patches; debt that the team cannot size.

Deal implications: quantified debt can be priced. Unquantified debt should be sized during diligence or covered by a holdback until it is.

Turning findings into deal terms

At the end of diligence, sort findings into three lists. Price items have a cost the buyer will carry and can be estimated. Structure items are risks that cannot be sized confidently, or that depend on seller behavior, and are better handled through representations, specific indemnities, escrow, holdbacks or earn-out conditions. Plan items are work the buyer accepts and schedules into the first 100 days. A short, evidence-backed list in each category is more useful to an investment committee than a long report with no prioritization.

Download the checklist

A spreadsheet version of this checklist, with columns for evidence, questions, red flags, deal implications, owner and status, accompanies this article. Download the checklist as a spreadsheet (CSV).

Talk to Arrive First

If you are preparing to buy or sell a software business and want an independent view of the technology, see our pre-acquisition due diligence service or get in touch to discuss your timeline.