Technical Due Diligence Checklist: What to Look At

Technical due diligence answers one question for an investor or acquirer: can this technology, and this team, support the plan the money is backing? It is not a code-quality score. A messy codebase that the team understands and can change quickly may be a smaller risk than a tidy one nobody dares touch. The checklist below covers the areas that most often change a valuation or a plan.

The areas at a glance

Area	What you’re trying to find out
Architecture	Will the system carry the growth in the plan, and what would have to change?
Code and delivery	How fast and safely can the team ship changes today?
Data	Is the data owned, clean, and legally usable for what’s planned?
Security	Are there exposures that would be expensive or embarrassing after closing?
Infrastructure and cost	What does it cost to run, and how does that scale?
Third parties	Which external services could stop, change price, or change terms?
Team	Who holds the knowledge, and what happens if they leave?

Architecture

• Draw, or ask for, a diagram of the main systems and how they connect. Compare it with what the engineers describe.
• Which parts would need to change to support the plan’s growth, or new products?
• Where are the single points of failure?
• Are there parts nobody wants to touch? Why?

Code and delivery

• How long does a small change take from idea to production?
• How often do releases cause incidents, and how quickly are they fixed?
• Is there automated testing on the parts that matter most, such as payments and calculations?
• How much of the code is generated, copied, or abandoned?

Data

• Where does the important data live, and who owns it: the company, a vendor, or a customer?
• Is it clean enough for what the plan needs, such as reporting, pricing, or AI features?
• Are there consents and legal bases for how it’s used?
• Is any critical data locked inside a third-party platform that’s hard to leave?

Security

• How are access, secrets and sensitive data handled in practice?
• Has there been a penetration test, and were the findings fixed?
• Who has production access, and is it reviewed?
• Any incidents, and how were they handled and disclosed?

Infrastructure and cost

• Monthly running costs, broken down, and how they grow with usage.
• Any reserved commitments or contracts that run past the deal.
• Is infrastructure defined as code, or configured by hand in a console?

Third parties

• List every external service the product depends on: payments, data providers, accounting connectors, AI APIs.
• For each: contract terms, pricing changes, and what happens to the product if it disappears.

Team

• Who knows each critical part of the system? Is it written down anywhere?
• What would happen if the two most senior engineers left?
• Is the team the right shape for the plan, or does it need to grow first?

Turning findings into something useful

Group findings by what they mean for the deal: things that must be fixed before closing, things that need budget in the first year, and things that are fine as they are. Attach a rough cost and time to each. “The data model won’t support multi-currency; about three months of work before the expansion in the plan” is useful. “Code quality: medium” isn’t.

Due diligence is a focused form of architecture review. If you need one done independently, an architecture review can be scoped around the deal’s specific questions.