Technical Due Diligence Checklist for Buying a Software Company

Request access in this order, because each area informs the next:

1. Architecture diagrams, repository list and the deployment process.
2. Read-only access to source control and the cloud accounts.
3. Security policies, recent penetration test reports and incident history.
4. Contracts for critical vendors and any open-source license inventory.
5. An org chart of engineering with tenure and roles, plus a call with the most senior engineers.

Ask the seller to walk you through a real deploy and a real bug fix, live. What they show tells you more than any slide deck, because you can see whether the process is routine or heroic.

You aren't grading style. You're looking for risk you'd inherit:

• Bus factor. Do commit logs show one or two people writing nearly everything? That is a retention risk, not just a code risk.
• Tests and releases. Is there an automated test suite that runs before releases, and how often does the team ship? Rare, scary releases suggest hidden fragility.
• Dependency age. Frameworks and libraries several major versions behind mean an upgrade bill you'll pay after closing.
• Data model and scaling limits. Ask what breaks first if usage doubles, and whether the answer is specific.
• Dead or duplicated systems. Several half-migrated services often mean a stalled rewrite.

A dependency and license scanner such as Snyk fits here, because it gives you a concrete list of outdated and vulnerable packages to price. Confirm in a demo how it covers the target's languages.

Sellers often describe security as fine, so ask for evidence. Request the latest audit report or attestation if one exists, the access-review history, and the list of who has production access today. Check whether former employees and contractors are gone from every system.

For vulnerability handling, ask how quickly the team fixes serious flaws and to see examples. CISA's federal directives are a useful yardstick: agencies had to patch critical vulnerabilities on internet-facing systems within 15 days and high ones within 30¹. A team that can't show any tracking of fix times is telling you something.

If compliance is a selling point, confirm what is real. If the target uses a compliance automation tool such as Vanta, ask how long its controls have been tracked and whether the evidence was collected steadily or assembled just before the audit. Have your own counsel review anything tied to regulated data.

Ask for twelve months of cloud invoices and map them to services. You want to know the unit cost of serving a customer and whether the bill is growing faster than revenue. Check whether infrastructure is defined in code or clicked together in a console, since the second makes migration and recovery slower.

Then look at reliability. Ask for the incident log, the on-call schedule and the last restore test of backups. A backup never restored is a hope, not a control. If the target runs an observability tool such as Datadog, ask for the uptime history and alert volume from it, not summaries.

Finally, list every account the business runs on: domains, cloud, payment processors, app store listings. Confirm they're owned by the company and not by an individual's personal login.

Sort every finding into three buckets and attach a cost or a decision to each:

• Red, deal-changing. The seller doesn't own key IP, a critical system has one person who understands it, or there's an unreported breach. Renegotiate price, add an escrow or holdback, or walk away.
• Amber, fixable with budget. Outdated frameworks, thin tests or missing documentation. Estimate the engineer-months and treat it as part of the purchase price.
• Green, note and move on. Style issues and small debts that don't affect operation.

For example, say the codebase runs on a framework that no longer receives security fixes. That's amber, and you'd estimate the upgrade work in months and ask the seller to credit it against the price. Feed the rest of your findings into your integration plan and your technology roadmap, so post-close work is budgeted from day one.