The Software Due Diligence Checklist

Software due diligence answers two questions for a buyer: can this product support the revenue plan being underwritten, and what will it cost to fix the parts that cannot. The working checklist covers eight areas: architecture and scalability, code quality, the engineering organization and its key-person risk, SDLC and release discipline, cloud cost trajectory, security posture, licensing and IP, and data readiness. A competent buy-side review runs two to four weeks alongside financial diligence, and its output is not a grade. It is a cost-to-fix register that moves purchase price, escrow terms, and the first-100-days plan. Here is what to examine in each area, and how the findings translate into the deal.

How to run the process

Sequence matters because access arrives in stages. Week one is documents and interviews: architecture diagrams, the security package, org charts, cloud invoices, and sessions with the CTO and lead engineers, where the questions below get asked before anyone verifies anything. Week two is verification: repository access, read-only cloud console access, software composition scans, ticket system exports. Weeks three and four are synthesis, pricing the findings and pressure-testing them with the deal team. Insist on direct system access rather than screen-shared tours; a target that will not grant read-only repository access to a diligence team under NDA is itself a finding. And run this in parallel with financial diligence, because the cloud bill, capitalized development costs, and engineering payroll all appear in both workstreams and should tell one story.

Architecture and scalability

The question is not whether the architecture is fashionable; it is whether the system can carry three to five times current load without a rewrite, because the rewrite is what the model never prices. Look for single points of failure, the honesty of the multi-tenancy story, how much of the platform runs on managed services versus bespoke infrastructure someone must operate, and whether horizontal scaling is real or theoretical. Ask for the most recent load test and the largest customer's usage profile, then compare that profile against the pipeline the sellers are projecting. A monolith is not a finding; a monolith whose deployment terrifies its own engineers is. The deliverable from this section is an estimate of what growth costs: the next 10,000 customers expressed as an engineering line item.

Code quality signals, without reading every line

Nobody reads a million lines in diligence, and nobody needs to. A day of repository analytics tells you more than a week of line-by-line review:

• Test coverage on the modules that touch money and customer data, not the vanity average across the repo
• Static analysis and linting wired into the pipeline, or absent
• Dependency freshness, and the count of known-vulnerable packages in production paths
• Commit concentration: how much of each core module is one person's work
• Defect escape and reopen rates pulled from the ticket system
• The age and tone of TODO and FIXME comments sitting in critical paths

Then read code in exactly two places: the most business-critical path, and the module the team seems least eager to discuss. Whether those samples match the metrics tells you whether the codebase is what management says it is, and the gap between the two is usually where the cost-to-fix register starts filling up.

The engineering organization and key-person risk

Systems live in heads before they live in documentation. Identify the three to five people who hold the architecture, the deployment process, and the oldest subsystems in memory, then establish whether they are employees or contractors, whether they intend to stay, and what retention costs. Check the contractor-to-employee ratio and where the contractors sit contractually, because IP assignment gaps tend to surface exactly here. Read the documentation the way a new hire would: if onboarding an engineer takes a quarter of shadowing one specific person, that person is a deal term and should be treated like one. Retention packages for named individuals are cheap against the alternative, which is the knowledge walking out in month three post-close while the integration plan assumes it stayed.

SDLC and release discipline

Release mechanics predict how fast the roadmap you are paying for can actually ship. Look for enforced code review, CI/CD that deploys without heroics, separated environments, a rollback story someone has actually exercised, and an incident history recorded in postmortems rather than folklore. Compare the stated release cadence against the repository's actual history for the trailing year, since the two diverge more often than not. A team that ships weekly with boring regularity can absorb the integration work coming after close. A team that ships quarterly behind a freeze window cannot, and the 100-day plan should be written to match the team you found rather than the one in the management presentation.

Cloud cost trajectory

Infrastructure spend is a gross margin input, and diligence keeps finding models where it is treated as fixed overhead. Pull twelve months of cloud bills and plot them against revenue and usage: cost growing faster than revenue is a margin problem compounding quietly under the growth story. Check unit economics per customer or per transaction, committed-use and reserved-capacity posture, egress exposure, and whether anyone owns cost as an ongoing discipline. It is common to find 10 to 20 percent savings within a quarter of close, which is pleasant but not the point. The diligence question is harsher: do the target's margin claims survive scale, or does the COGS line eat the thesis at exactly the growth rate being underwritten.

Security posture

Certifications are the floor, not the finding. A SOC 2 report or ISO 27001 certificate says a program exists; diligence establishes whether it is real. Check the recency and scope of the last penetration test and whether findings were remediated or merely acknowledged in a tracker. Review access hygiene, secrets management, and the age distribution of the vulnerability backlog. Ask directly about incident history, then compare the answer against what the logs and postmortems show, because the deltas are informative in both directions. An unremediated breach or a critical finding in a customer-facing system is a purchase price event, and it is considerably better discovered in diligence than in the first board meeting after close, when it becomes the buyer's disclosure problem.

Licensing and IP: the open source audit

Run software composition analysis across the codebase and reconcile the output against the target's own open source inventory, which is nearly always shorter than reality. What matters is copyleft exposure in the wrong places: GPL or AGPL components linked into distributed or customer-facing code can contaminate proprietary IP, and AGPL anywhere in a SaaS backend deserves specific review by counsel. Confirm signed IP assignment agreements exist for every employee and, more urgently, for every contractor who ever touched the code, including the agency from six years ago. Verify that third-party and embedded licenses transfer with the deal rather than terminating on change of control. And ask about AI-generated code provenance and policy, because buyers' counsel has started asking whether the codebase contains code nobody can claim authorship of.

Data readiness

The data asset is often half the thesis, especially where AI plans are attached to the deal model. Examine schema coherence and whether the data a model would train on exists at the quality claimed, rather than as exports nobody has actually joined. Confirm the target holds the contractual right to use customer data the way the thesis assumes, because we have the data and we may use the data are different sentences with different values. Map where personal data lives against the privacy obligations that transfer with the deal. A migration and integration estimate belongs here too: data that takes a year to untangle delays every synergy built on top of it, and that delay belongs in the model now.

Turning findings into price

Every finding lands in one of four buckets: fix before close, fix in the first 100 days, price it into the deal, or walk. The instrument is the cost-to-fix register: each finding carries a remediation estimate, a timeline, and an owner, then the register gets summed and staged. On mid-market software deals these registers routinely total 5 to 15 percent of enterprise value, which is negotiating material rather than trivia. Structure follows the register: price adjustments for permanent impairments, escrows or holdbacks for items that are fixable but unproven, remediation covenants with dates for the rest. The same register then becomes the integration team's first backlog, which is the quiet payoff of doing this properly: the 100-day plan writes itself while the deal is still being priced.

Where BD Emerson fits

Our software due diligence practice runs this checklist with people who have built and operated the systems they are grading, and our broader technology due diligence practice extends the same discipline across infrastructure, IT operations, and security when the target is more than a codebase. Findings arrive priced and mapped to the deal calendar, because a diligence report that cannot move a number is a very expensive book report.