Scale ScoreTechnical due diligence checklist
This is the checklist a reviewer works through when evaluating a software company, organised the way the process actually runs: cheapest signal first, deepest last. It works in both directions. If you are buying, it is what to ask. If you are being bought, it is what to prepare before anyone asks.
Each section includes what a weak answer looks like, which is the part most published checklists leave out and the part that makes the list usable if you have never run a diligence process before.
For the wider context this sits in, see technical due diligence. For how these questions get sent and answered formally, see the due diligence questionnaire.
1. Architecture and technology
Establishes whether the foundation supports the buyer's plan for the product.
- Current architecture diagram, dated, and matching what is actually deployed
- Languages, frameworks and major versions, with end-of-life dates for each
- Which components are monolithic, which are separate services, and why
- Data model overview and the size of the largest tables
- Known scaling limits: what breaks first at 10x current load
- Any component nobody on the current team has modified in over a year
Weak answer: An architecture diagram that has to be redrawn for the diligence process, or that nobody can confirm is current.
2. Delivery and engineering process
The best predictor of whether the acquirer's roadmap is achievable. Scored against the DevOps maturity model.
- Deployment frequency to production, measured rather than estimated
- How a change gets from a developer's machine to production, step by step
- Automated test coverage, and whether tests gate merging
- Time from code complete to released, and what the manual steps are
- Rollback procedure, and the last time it was used in anger
- Branching model and code review practice
Weak answer: Deployment described as a process rather than measured as a number, or a release that requires a named individual to be available.
3. Security and compliance
Often the fastest route to a deal-relevant finding, because it maps directly to the buyer's customer base.
- Access control: who can reach production, and how that is granted and revoked
- Encryption at rest and in transit, and where sensitive data lives
- Whether production data is used in development or test environments
- Vulnerability scanning and patching cadence for dependencies
- Most recent penetration test or security audit, and what it found
- Security incident history and how each was handled
- Relevant compliance posture: SOC 2, HIPAA, GDPR, PCI as applicable
Weak answer: Credentials committed to the repository, shared production logins, or production data copied into a staging environment.
4. Infrastructure and operations
What it costs to run, and what happens when it stops running.
- Hosting arrangement and monthly infrastructure cost
- How that cost scales with users or usage
- Monitoring and alerting: what is watched, and who gets paged
- Backup procedure, retention, and the last time a restore was tested
- Documented disaster recovery plan with an actual recovery time objective
- Uptime history and the three most recent significant incidents
Weak answer: Backups that exist but have never been restored. This is extremely common and reliably alarming.
5. Third-party dependencies and licensing
The area most likely to produce a genuine surprise, because it is rarely tracked internally.
- Inventory of open source dependencies with their licenses
- Any copyleft licenses (GPL, AGPL) inside proprietary components
- Commercial licenses and whether they survive a change of control
- Critical third-party services and what happens if one disappears
- Any code written by contractors, and whether IP assignment is documented
Weak answer: No dependency inventory at all, or an assumption that everything is MIT-licensed without having checked.
6. Team and key-person risk
Consistently the finding with the largest effect on deal terms, and the one companies prepare for least.
- Org chart with tenure and area of ownership
- Which systems have exactly one person who understands them
- Documentation state: what exists, when it was last accurate
- Contractor and outsourced dependency, and the ratio to permanent staff
- Retention risk: who is critical, and what is keeping them
- Onboarding time for a new engineer to first meaningful contribution
Weak answer: A single engineer who is the only person who can deploy, or who wrote a core system nobody else has read.
How to use it
Two suggestions that change the quality of what you get out of this:
- Ask more than one person. Give the same list to the engineering lead and to two engineers separately. Where the answers disagree is the most valuable output, and a single-respondent process discards it entirely.
- Score it, do not just answer it. Free-form responses are hard to compare, either across targets or against the same company six months later. Rating each area on a fixed scale turns the checklist into something you can track. The DevOps maturity model gives you that scale for sections 2 and 4.