Decide what you are buying
Diligence looks different depending on the thesis. Buying a customer base means the software only has to keep working. Buying a product to build on means its architecture genuinely constrains your roadmap. Buying a team means the code matters least of all.
State the thesis first, because it determines which findings are material and which are noise.
Verify ownership before anything else
This is the category that kills deals, and it is frequently discovered late. Confirm that the company actually owns what it is selling.
- Contractor agreements with explicit IP assignment, for everyone who contributed
- Open-source licences, particularly copyleft in distributed products
- Third-party components and whether their licences survive a change of control
- Domains, cloud accounts, and app-store listings held by the company rather than an individual
- Customer contracts with assignment or change-of-control clauses
Measure delivery, not elegance
Ask how long it takes to get a one-line change into production, and ask to watch. The answer reveals the state of testing, deployment, environments, and team confidence in a way no code review does.
A tidy codebase that takes three weeks to release is a worse asset than a messy one that ships daily, because the second can be improved and the first cannot easily be moved.
Look at the team and the bus factor
Find out how many people genuinely understand each critical system. A single irreplaceable engineer is a material risk, and their intentions post-acquisition are a legitimate diligence question.
Review commit history for concentration, check documentation for onboarding material, and ask how long the last new engineer took to become productive.
Separate expensive from ugly
Every codebase looks bad to someone who did not write it. The question is not whether it is attractive but what it will cost you to do what you intend to do next.
Cheap to live with: inconsistent style, dated frameworks that still work, missing tests in stable areas. Expensive: a data model that blocks your roadmap, no deployment automation, hard-coded single-tenancy in a product you plan to sell to enterprises, security debt in a regulated context.
Check the operational reality
Incident history, uptime, monitoring coverage, backup restore evidence, and the current cloud bill against revenue. These describe what you are taking on operationally from day one.
Ask specifically about the last serious outage: what happened, how long it took, and what changed afterwards.
Price the findings
Diligence output should not be a list of concerns. It should be an estimate: what must be fixed before it is safe to proceed, what should be fixed in year one, and what those cost in time and money.
That converts technical findings into something the deal team can actually act on — a price adjustment, a warranty, or a walk-away.