Software due diligence checklist: what to inspect before you inherit a product
Software due diligence checklist for code, releases, data, security, vendors, and 30-day handover risks before a deal.
A software due diligence checklist is useful when you are about to buy a product company, inherit a codebase, fund a rebuild, or sign a long contract with a software vendor.
The dangerous part is not the code review itself. The dangerous part is looking at a demo, hearing that the stack is modern, and assuming the product can be maintained. A system can look fine in a sales call and still hide missing tests, hard-coded credentials, one-person knowledge, weak deployment paths, or data problems that will cost months later.
This guide is written for founders, investors, CFOs, CTOs, and operators who need a practical technical check before money or responsibility changes hands. It is not a legal due diligence list. It is the engineering and delivery side: what works, what breaks, what depends on one person, and what it will cost to keep the software alive.
Software due diligence checklist before you trust the demo
Start with evidence, not opinions. A polished demo tells you that one path worked once. Due diligence needs to show whether the team can run, change, release, support, and secure the product when normal problems appear.
Ask for these basics before the first technical workshop:
If the seller or vendor cannot provide this within a few days, that is already a finding. It may not kill the deal, but it changes the price, timeline, and handover plan.
Check whether the codebase can be run from zero
The simplest due diligence test is also one of the most revealing. Can a developer who has not worked on the product clone the repo, follow the README, and run the system locally or in a test environment?
Track the hidden steps. Someone may need to send a private .env file over chat. A database dump may live on one laptop. A package registry token may belong to a former contractor. The app may start only after three undocumented commands. Each hidden step is future delivery risk.
A clean setup does not mean the product is perfect. It means the knowledge is not trapped in one person. If setup takes a full day with hand-holding, include that in the due diligence memo. You are buying the software and the operating knowledge around it.
Review architecture for change risk, not elegance
Architecture review should answer one question: how expensive is the next important change? You do not need a perfect diagram. You need to know where the product is fragile.
Look for:
A due diligence report should separate ugly from risky. Ugly naming is annoying. A payment workflow with no tests and three manual database fixes per month is risk. A legacy module can be acceptable if it is stable, documented, and boxed in by clear interfaces.
For a deeper cleanup pass after the deal, use our technical debt audit checklist. Due diligence finds the risk. The audit turns it into a backlog.
Inspect release, rollback, and environment control
A product is not production ready because it has production users. It is production ready when the team can release a small change, spot a problem, and roll back without panic.
Check:
One useful question: when was the last production incident, and what changed afterward? A team with honest incident notes is usually safer than a team that claims nothing ever breaks.
Assess tests around money, permissions, and data
Do not ask only for test coverage percentage. Coverage can be high while the important paths are barely checked. Ask where a regression would hurt the business.
Review tests around billing, permissions, data import, exports, integrations, notifications, and admin actions. If the product handles personal data, check access control tests and audit logs. If it moves money, check rounding, refunds, reconciliation, and duplicate event handling.
A small but meaningful test suite is better than thousands of brittle snapshots. The question is whether the team knows which parts must not break.
Map data ownership and migration risk
Most software due diligence misses data risk until late. That is expensive. A product can have decent code and still carry messy customer records, duplicate accounts, unclear consent, missing deletion paths, or manual corrections that never made it into the system rules.
Ask these questions:
For European teams, GDPR questions are not paperwork at the end. They affect architecture, logs, backups, analytics, and support tooling. If nobody can explain deletion and export paths, record that as a real delivery risk.
Evaluate team and vendor dependency
Software risk often sits outside the repository. A product may depend on one contractor, one cloud account, one undocumented vendor contract, or one founder who approves every release. Due diligence should make that visible.
List the people and vendors needed to operate the product for the next 90 days. Include developers, DevOps, product owner, support, security, external APIs, hosting, payment providers, email providers, analytics, and any no-code tools in the workflow.
Then ask what happens if each one disappears for two weeks. If the answer is "we wait", you have a continuity problem. It may be fixable, but it needs a handover budget.
If you are comparing several external partners before a build or acquisition support project, our software vendor selection checklist covers the questions to ask before signing.
Build a 30-day remediation plan
The output of software due diligence should not be a scary list with no decisions. It should sort findings into three groups: deal blockers, price or scope adjustments, and post-close remediation work.
A practical first 30 days might look like this:
Do not try to fix every code smell immediately. First make the product safe to operate. Then improve the parts that slow changes or create business risk.
Red flags in software due diligence
Some findings deserve more attention than normal technical debt.
Watch for:
None of these automatically means walk away. They do mean you should change the deal, add a transition budget, or slow down until the risk is understood.
FAQ: software due diligence checklist
What is software due diligence?
Software due diligence is a technical review of a product, codebase, team, infrastructure, data, and operating process before an acquisition, investment, vendor change, or major contract. It shows what can be trusted and what will need money after the deal.
What should a software due diligence checklist include?
It should include repository setup, architecture, release process, environments, tests, security, data ownership, integrations, vendor dependencies, incident history, documentation, and a remediation plan with owners and timelines.
How long does software due diligence take?
A focused review of a small or mid-sized product often takes one to two weeks if access is ready. Complex platforms, regulated data, weak documentation, or several vendors can push the review to three or four weeks.
Who should run software due diligence?
Use senior engineers who can read code, understand infrastructure, and explain risk in business terms. For acquisitions or vendor handovers, include someone who has operated production systems, not only someone who can review architecture slides.
Is software due diligence the same as a code audit?
No. A code audit focuses on code quality and technical risk. Software due diligence also checks delivery process, people, vendors, accounts, data, security, documentation, and the cost of taking responsibility for the product.
Need a clear view before you inherit a codebase?
Syntanea helps European companies assess software products before acquisitions, vendor changes, rescue projects, and long technical commitments. We review the code, delivery path, data risk, infrastructure, and team dependency, then turn the findings into a plain decision memo.
If you need to know whether a product can be trusted, talk to Syntanea. We can run a focused due diligence review and give you a practical handover or remediation plan.