Technical Due Diligence Checklist

Technical due diligence is a risk process

Technical due diligence answers one question: what technical risk is hidden in this company, and what would it cost to fix? It is not a code review for its own sake, and it is not a pass or fail exam. It is an evidence-based assessment that helps a buyer, investor, or board price and plan around what they find.

This checklist covers the main areas to examine, the evidence to request, and how to present findings so they are actually useful.

Who needs it and when

• Investors before a funding round, especially for a technical product
• Acquirers before an acquisition or acqui-hire
• Boards when asking whether technology is being run well
• Founders preparing for diligence, so there are no surprises
• Companies replacing or auditing an external development vendor

Timing matters. Run it early enough that findings can change a decision, not so late that it only documents a decision already made.

Set scope and timebox first

Unbounded due diligence expands forever. Decide up front:

• What decision will this inform? (invest, acquire, partner, fix, exit)
• How much access is available? (code, systems, people, contracts)
• What is the timebox? (often days to a few weeks)
• What is the output? (findings report with risk ratings and remediation)
• What is explicitly out of scope?

A focused, well-scoped review beats a sprawling one that arrives after the deadline.

1. Architecture and system design

• What are the main components, and how do they communicate?
• Is the architecture documented, and does the documentation match reality?
• Where are the single points of failure?
• How is data owned and where does it live?
• Are there known scaling ceilings, and where are they?
• Is the system over- or under-engineered for the business stage?

The goal is not to judge taste. It is to identify decisions that constrain the business or that would be expensive to reverse.

2. Code and engineering quality

• Is the codebase understandable to someone new?
• Is there consistent structure, naming, and error handling?
• What is the test coverage like, and is it meaningful?
• How much dead code, duplication, or abandoned experiments exist?
• Are dependencies current, and are there known vulnerabilities?
• Is the source of truth in version control, or are there local-only changes?

You do not need to read every file. Sample the critical paths and the parts that change most often.

3. Security and access

• How are secrets and credentials managed?
• Is authentication and authorization implemented consistently?
• How is customer data stored, encrypted, and accessed?
• What is the patch and dependency-update process?
• Is there logging and monitoring for security-relevant events?
• Who has production access, and is it reviewed?
• Are there known incidents, and how were they handled?

Be careful about scope here. Technical due diligence can identify risk and gather evidence, but it is not a certification or legal attestation.

4. Data and integrations

• Where does authoritative data live for each entity?
• How are data changes propagated between systems?
• What happens when an integration or third-party service fails?
• Is there data duplication that can drift out of sync?
• How is data exported if the company needs to leave?
• Is there a plan for backup, restore, and retention?

Integrations are a common source of hidden cost. They are also hard to replace once embedded in operations.

5. Delivery process and team

• How does work move from idea to production?
• How are releases tested and deployed?
• How long does a typical change take to reach production?
• Who reviews code, and who can approve a release?
• How is on-call and incident response handled?
• Is there a single person who holds critical knowledge?

The key question is bus factor: how much breaks if one or two people leave?

6. Team, knowledge, and vendor dependence

• What is the team structure, and what seniority exists?
• Is critical knowledge documented or only in people's heads?
• Are key services provided by a vendor, and what are the contract terms?
• How would the company transition away from that vendor?
• Are there license, IP, or contractor-agreement gaps?

Vendor and key-person dependence is one of the most under-priced risks in due diligence.

7. Cost and operations

• What does infrastructure cost today, and how does it scale?
• Which costs are fixed, and which grow with usage?
• Are there unused or duplicated services?
• Is spend tracked and attributed?
• What is the cost of the current reliability level?

Cost risk is easy to measure and often ignored until it is urgent.

8. Product and roadmap alignment

• What is promised to customers, and what is actually delivered?
• Does the roadmap match the team's capacity?
• Are there large commitments that are not funded?
• Is there technical debt that blocks the roadmap?

Evidence to request

Ask for artifacts, not assurances:

• Architecture diagrams and system documentation
• Repository access or a representative sample
• Test and CI/CD configuration
• Deployment and release history
• Incident and outage records
• Security policies and access reviews
• Vendor and license agreements
• Hosting bills and cost breakdowns
• Team structure and key-person dependencies

If an artifact does not exist, that is itself a finding.

Common red flags

• No architecture documentation, or documentation that contradicts the code
• One person who knows how everything works
• No automated tests on critical paths
• Secrets committed to the repository
• Production changes made manually with no review
• Integrations with no failure handling
• Rapidly rising infrastructure cost with no tracking
• A vendor relationship with no exit plan
• Roadmap commitments far beyond team capacity

Present findings as risk, not blame

A useful report rates each finding by likelihood and impact, separates must-fix from monitor, and estimates remediation effort. It should answer: what could go wrong, how bad would it be, and what would it cost to reduce the risk?

Findings should be verifiable. "The payment path has no automated regression test" is useful. "The code is bad" is not.

FAQ

How long does technical due diligence take?

It depends on scope and access. A focused review of a single product can take days; a larger platform with integrations and compliance obligations can take a few weeks. Define the timebox and the decision it informs before starting.

Can technical due diligence be done without full code access?

Partially. Architecture, delivery, team, cost, and vendor risk can be assessed with documentation, interviews, and system access. Code and security findings need repository and environment access. Limited access should be stated as a limitation in the report.

Is technical due diligence the same as a security audit?

No. Technical due diligence covers architecture, code, delivery, team, cost, and risk. A security audit goes deeper on vulnerabilities and controls. They overlap, but they are different scopes and different outputs.

Who should run technical due diligence?

Someone independent of the team being assessed — an external consultant or a technical advisor without a stake in the outcome. Independence matters because the builder should not be the only party verifying its own work.

How does Kairosys approach it?

Our software development consulting service includes technical due diligence for investors, acquirers, and boards. Architecture and code findings often draw on software architecture and consulting, and verification evidence can be gathered through quality assurance and software testing.