The demo works beautifully. The only person who knows how to deploy it is leaving next month.
Software due diligence exists partly to find that sentence before it becomes your problem.
The short answer: assess what the software does, who owns it, how it is built and operated, and what risks or costs the buyer inherits. Ask for demonstrations and records alongside explanations. A repository review is one part of diligence, not the whole exercise.
Define the decision and access
An investor deciding whether to fund growth needs different depth from a buyer taking operational control. Agree the transaction question, systems in scope, materiality and time available. Identify limitations in the final findings.
Arrange read-only access where appropriate and use controlled environments for demonstrations. Do not run intrusive security tests against production without explicit authorisation. Handle confidential code, customer data and commercial material under the agreed process.
The review should inform a decision, not produce the longest possible list of imperfections. Almost every functioning software business has technical debt. The question is which liabilities matter to this transaction.
Inspect eight evidence areas
| Area | Evidence to request | Decision it informs |
|---|---|---|
| Ownership | Contracts, assignments, licences and component inventory | Rights to operate and develop |
| Architecture | Current system map and critical dependencies | Scalability and change constraints |
| Security | Findings, remediation, access model and incident history | Exposure and required corrective work |
| Delivery | Recent changes, tests and release records | Ability to change safely |
| Operations | Monitoring, incidents and restore demonstration | Continuity and resilience |
| Team | Responsibilities, documentation and key-person dependence | Handover and retention risk |
| Cost | Bills, usage drivers and commitments | Sustainable unit economics |
| Product | Usage evidence and essential third parties | Dependence behind the proposition |
Follow one change from request to production
Choose a recent material change. Ask the team to show the requirement, code review, tests, deployment and monitoring. Observe how approvals and rollback actually work, rather than relying only on the documented ideal.
Then inspect a failed change or incident. What happened, how was it detected, and what changed afterwards? A team that can explain a failure candidly may be more dependable than one claiming never to have had any.
Use DORA’s research as background for delivery performance, but avoid turning a single metric into a universal judgement. Context, trend and evidence matter.
Test continuity
Ask someone other than the usual operator to explain deployment and recovery. Review who controls cloud accounts, domains, repositories and third-party services. Identify personal accounts or undocumented manual steps.
A restore demonstration should establish what data is recovered, how long it takes and who can perform it. A backup schedule is weaker evidence than a successful restoration.
Check the support and maintenance status of important dependencies. The open-source security checklist can support that inspection, but proprietary dependencies need similar operational scrutiny.
Translate findings into a buying decision
Classify findings by consequence and urgency. Separate an immediate blocker, a condition to resolve before completion, a funded remediation item and an ordinary improvement. State the evidence, confidence and uncertainty for each.
Estimate remediation with the people who understand the system. Use ranges where the work is uncertain and identify what would reduce that uncertainty. Avoid a spurious exact number derived from a brief inspection.
Ownership questions require the appropriate legal review. A technical reviewer can identify missing evidence and architectural use, but should not invent a definitive IP opinion from a repository licence file.
What should the report contain?
Lead with the decision implications, then the material findings, evidence, limitations and proposed actions. Include a prioritised remediation plan with accountable owners and dependencies.
The useful output is a clearer transaction decision. A forty-page catalogue of coding preferences is less valuable than discovering the three conditions that could prevent the business from operating after handover.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.
