Technical Due Diligence Checklist for Software Acquisitions

1. Write down the decision before requesting access

A reviewer needs more than a repository link. State what the buyer expects to own and do: retain the existing product, replace the founder, migrate infrastructure, integrate another business, or support a growth plan. The same codebase can be acceptable for one plan and expensive for another.

Choose the assumptions whose failure would affect the transaction. Name a decision owner and an evidence deadline. This turns diligence into a bounded investigation rather than an unrestricted search for imperfections.

• Example question: can a replacement operator deploy and recover the service without the founder?
• Evidence requested: account inventory, deployment instructions, recovery records, and a walkthrough by the intended successor.
• Decision affected: required handover conditions, transition support, and the first operating budget. Missing evidence should stay an open condition, rather than becoming an automatic pass.

2. Request an evidence pack that matches the scope

Use authorized, preferably read-only access. Ask for the relevant revision, environment, and time period so that a document, demonstration, and code sample can be reconciled. Customer records, production write privileges, and shared passwords are not normally prerequisites for an initial review.

3. Separate an assertion from a proportionate verification

A statement that backups run every day establishes a claimed process. A backup-job log supports execution. A witnessed restore, together with checks that the application and required external state work, supports a narrower recovery conclusion. None of these alone establishes that every disaster scenario is covered.

Apply the same progression to other claims. A dashboard showing successful releases is not evidence that rollback works. Passing tests do not establish coverage of authorization failures. A dependency scan does not replace investigation of how a vulnerable component is used.

• Record the claim, source, reviewed revision, environment, check, observed result, and limitation.
• Agree non-intrusive verification methods first. Testing that could affect production or third parties needs separate authorization.
• Record inaccessible areas explicitly. Interview confidence is not a substitute for source or operational evidence.

4. Translate the finding into an ownership consequence

The acquisition question is not whether a system has technical debt. It is whether the debt changes operating continuity, safe development, the growth plan, or the resources required after closing. A finding should identify the affected workflow or asset, the conditions under which failure matters, and the available response.

Treat potential consequences as conditional unless evidence establishes that they occurred. For example, an absent recovery exercise supports uncertainty about recovery readiness. It does not establish a historical outage or a quantified revenue loss.

• Resolve before closing: a required account cannot be transferred, or a material access boundary fails in an authorized check.
• Plan for the transition: a successor has not demonstrated deployment or incident handling independently.
• Budget after closing: a scoped upgrade or refactor is needed to support an agreed product change. These are example decision categories, not universal transaction rules.

5. Ask what an engineering estimate actually includes

An estimate needs a defined outcome, assumptions, dependencies, and completion evidence. Separate discovery, implementation, regression checks, release coordination, and operating validation. State whether those activities are included or excluded; a task list that omits them can create an understated budget.

Engineering days are not calendar days. Parallel work depends on available people, skills, review capacity, and system dependencies. A monetary scenario additionally needs explicit role rates and a cost basis. Without those inputs, an effort range may be useful while a currency total would be misleading.

6. Know when a checklist needs specialist follow-up

OWASP ASVS offers requirements for assessing application security controls; NIST SSDF describes secure development practices. They can help structure questions, but neither a reference to a framework nor completion of this checklist certifies the target. The cited resources are starting points for defined checks, not endorsements of an engagement.

Formal penetration testing, IP ownership opinions, regulated compliance, financial diligence, and specialist infrastructure questions may need separate expertise. Identify that need early and confirm availability rather than assuming a general technical reviewer covers it.

7. Finish with a brief the buyer can act on

Before commissioning work, agree the target and technical boundaries, priority decisions, evidence access, verification depth, exclusions, deliverables, timeline, and fee. Require a report that explains evidence gaps and confidence, plus a discussion in which the investment team can challenge the conclusions.

The useful output is a defensible account of the risks being acquired and the next decisions. It may support proceeding, targeted follow-up, an operating plan, or reconsideration of an assumption. A checklist alone cannot determine valuation or whether to complete the transaction.