Technical Due Diligence Checklist for Buying or Investing in Software

Software technical due diligence should test whether the product can support the commercial plan, whether material security, data or ownership risks exist and what investment will be required after the transaction. It is not a code-style inspection and cannot guarantee that no defect remains.

Scope the review to the decision. An acquisition, minority investment, supplier onboarding and product rescue need different depth. Legal, financial, tax, privacy and regulatory conclusions require qualified advisers; the technical review supplies evidence for those workstreams.

Define the transaction questions

Start with the investment thesis and planned change. Will the product enter new markets, add enterprise tenants, handle more sensitive data, integrate with a portfolio or reduce founder dependence?

Turn these into testable questions. “Can it scale?” becomes “Which components constrain the forecast workload and what evidence supports the capacity estimate?”

Product and customer fit

Review product scope, active user journeys, release maturity, customer-specific forks and roadmap commitments. Compare sales claims with live behaviour and documentation.

Identify manual operations hidden behind the interface. A team may compensate for software limitations through spreadsheets or database edits, affecting margins and continuity.

Intellectual property and account control

Inventory repositories, design assets, infrastructure code, domains, app-store accounts, third-party services and licences. Confirm ownership with legal advisers.

Check contributor and contractor arrangements, open-source obligations and whether critical assets sit in personal accounts. The business should be able to access and operate production without one individual.

Architecture and maintainability

Examine system boundaries, dependencies, data model, tenancy, integrations and deployment. Sample high-change and high-risk code paths rather than grading every file.

Look for tests, coding standards, decision records and the ability of a new developer to run the system. Complexity may be justified; undocumented complexity is a cost.

Use the SaaS Architecture Checklist for product-scale controls.

Security review

Assess identity, authorisation, secrets, dependency management, logging, vulnerability response, API exposure and privileged access. Review recent incidents and remediation evidence.

OWASP’s API Security Top 10 provides a useful reference for authorisation, resource use and inventory risks. Match depth to data and transaction consequence; do not declare software “secure” from a checklist alone.

Data and privacy engineering

Map data categories, sources, tenants, stores, processors, retention, export, deletion and backups. Test whether permission and lifecycle claims can be executed technically.

Profile integrity and migration history. Identify duplicated sources of truth and manual correction scripts. Relevant advisers should interpret privacy obligations; technical diligence confirms architecture and evidence.

Cloud and operations

Review accounts, environments, regions, network exposure, cost allocation, monitoring, backups, recovery and incident responsibilities. Verify that deployed resources match documentation.

Ask for a restoration demonstration or recent test evidence. A backup configuration is not the same as recoverability.

Delivery and quality

Inspect source control, code review, CI/CD, test layers, release approval, database migration and rollback. Compare release records with incidents and customer commitments.

GitHub describes CI/CD as automating build, test and deployment pipelines in its Actions overview. The product may use another tool; evidence and repeatability are what matter.

Team and key-person dependency

Map product, architecture, platform, security and support ownership. Review documentation and on-call/incident practice. Identify knowledge held only by founders or contractors.

Assess hiring plan against the commercial roadmap. The answer may be transition and documentation, not replacing the existing team.

Third-party and vendor dependency

Inventory payments, identity, AI, messaging, analytics and industry APIs. Review spend, contractual limits, data location, rate limits, deprecation and exit.

Read Avoiding Vendor Lock-In to distinguish useful dependency from unmanaged concentration.

Economics and future investment

Analyse cloud and licence costs by environment and workload where possible. Identify cost drivers and customer-specific overhead. Do not extrapolate from one month without seasonality or growth context.

Estimate remediation in bands: transaction-critical, first 100 days, roadmap-enabling and normal improvement. Avoid false precision before findings are validated with the team.

Evidence request list

• Architecture and data-flow diagrams.
• Repository and dependency inventory.
• Deployment/runbook documentation.
• Cloud and third-party account list.
• Security policies, tests and incident records.
• Backup and recovery evidence.
• Product roadmap and major customer commitments.
• Cost reports and licence tiers.
• Data retention/export/deletion processes.
• Team responsibilities and contractor dependencies.

Use a secure data room and least-privilege access. Do not copy production personal data into the review unnecessarily.

Rating findings

For each finding, record evidence, business consequence, likelihood/uncertainty, affected roadmap, recommended action and estimated effort range. Separate fact from inference.

A long list of low-severity style observations can distract from one material access or continuity risk. Prioritise decision relevance.

Validate representations with samples

Select representative evidence rather than accepting screenshots or policy documents alone. Trace a recent release from issue through review, test and deployment. Select a critical incident and inspect detection, communication, correction and prevention. Sample access removal, backup restoration and dependency updates.

Where time prevents verification, label the statement unverified and explain the decision it affects. Absence of evidence is not automatically evidence of failure, but it reduces confidence and may justify a condition, warranty or post-transaction action.

Turn findings into a transition plan

Separate pre-close conditions, first-30-day controls, near-term stabilisation and longer-term product investment. Identify owners, dependencies and indicative effort ranges. Protect critical staff and account access immediately while avoiding disruptive architectural change before the operating context is understood.

A useful diligence report helps the buyer act after the transaction. It should leave a traceable evidence index, not only a red-amber-green slide deck.

Frequently asked questions

Can diligence be completed without repository access?

A preliminary review can use demonstrations, architecture and operating evidence, but code and configuration access increase confidence. State the limitation and any condition before transaction close.

Is technical debt always a deal breaker?

No. Every product has debt. The question is whether it is understood, whether it blocks the plan and whether the team can address it at an acceptable cost.

Should the diligence team prescribe a rewrite?

Only with strong evidence. Incremental stabilisation, component replacement or team investment may preserve more value. Review How to Rescue a Failing Software Project before using rewrite as a universal remedy.

AUZtec Innovations delivers technical reviews across product, software, data, security and cloud. We can align the depth to the transaction decision and produce a prioritised evidence record rather than a generic score.

Where the transaction raises material protection concerns, our security and performance engineering capability can turn diligence findings into a scoped remediation programme.