The Technical Due Diligence Playbook

A structured approach to technical due diligence for M&A, investment, or partnership decisions.

Technical due diligence is not a code review. It is a risk assessment. The deal will close or not based on commercial terms, not on whether the codebase is pretty. Your job is to surface the risks the deal team needs to price, the risks they need to walk away from, and the risks they can mitigate after close.

This is the playbook I run for investment, acquisition, and serious partnership decisions. Adjust the depth based on the size of the bet.

Phase 1: Set the brief (Days 1 to 2)

Before any access is granted, get clarity on what the diligence is for.

1. Understand the deal thesis. Is this a talent acquisition, a product acquisition, a capability acquisition, or a financial play? Each one weights the technical findings differently.
2. Define the questions to answer. Typically: can we operate this? Can we integrate this? What will it cost to do either? Are there dealbreakers?
3. Agree on the report format. Executive summary, risk register, recommendations. Two to four pages plus appendices is usually right.
4. Set the timebox. Two to four weeks for most deals. Longer for complex carve outs.
5. Establish the access plan. Repos, infrastructure, data room, interviews. NDAs in place before anyone shares anything sensitive.

Phase 2: Architecture and code (Days 3 to 7)

Spend the first technical week on the system itself.

1. Get the architecture diagram. If they cannot produce one, that is information.
2. Walk the runtime. What runs where, who talks to whom, where state lives.
3. Read the spine of the codebase. Not all of it. The entry points, the domain models, the integration boundaries.
4. Sample the breadth. Pick three random pull requests from the last quarter and read them carefully. They tell you more about the team than any architecture diagram.
5. Score against a simple rubric:

• Modularity and coupling.
• Test coverage where it matters (not raw percentage).
• Code consistency across modules.
• Use of dependencies, including any abandoned or insecure ones.
• Build and deploy automation.

Write down the things that surprised you. Surprises are usually risks.

Phase 3: Operations and reliability (Days 8 to 11)

Code is only half the story. How they run it is the other half.

1. Review monitoring and alerting. What pages, what does not, who responds.
2. Pull incident history for the last twelve months. SEV1s, SEV2s, post mortems. Patterns matter more than individual events.
3. Review SLOs and uptime. Compare to what they market. Discrepancies are findings.
4. Examine the deployment pipeline. Frequency, rollback story, change failure rate.
5. Check the on call setup. Rotation, escalation, burnout signals.
6. Look at backups and disaster recovery. When was the last actual restore test?

Phase 4: Security and compliance (Days 10 to 14)

Run this in parallel with operations. Pull in a specialist if the surface area justifies it.

1. Authentication and authorization model. Roles, scopes, multi tenancy boundaries.
2. Data classification and handling. PII, payment data, regulated data, where it lives, who can see it.
3. Third party access and secrets management. How keys rotate, who has production access.
4. Compliance posture. SOC 2, ISO 27001, HIPAA, GDPR, whichever applies. Review the last audit report and the gaps.
5. Vulnerability history. Past incidents, disclosed and undisclosed. Penetration test reports if available.
6. Supply chain. Dependencies, base images, signed artifacts.

Earlier in my career working on regulated systems I learned that compliance documents and operational reality often diverge. Always check both.

Phase 5: Team and process (Days 12 to 16)

Acquiring code without people is acquiring liability. The team is usually the most valuable asset.

1. Org chart and tenure distribution. Concentration of knowledge in a few people is a real risk.
2. Interview the technical leaders. Two to four people. Open ended questions about what they would change, what scares them, what they are proud of.
3. Sample interview engineers. One or two ICs. Are they aligned with leadership's view? Do they know how the system actually works?
4. Hiring and retention. Recent attrition, hiring pipeline, compensation philosophy.
5. Engineering practices. Code review, testing, on call, planning cadence.
6. Documentation. Onboarding docs, runbooks, ADRs. The state of the documentation tells you about the culture.

Phase 6: Cost and economics (Days 14 to 18)

Technology costs money. Surface it.

1. Cloud and SaaS spend. Last twelve months by service. Trajectory.
2. Per unit economics. Cost per active user, per transaction, per inference. Where does it scale linearly versus sub linearly?
3. Contract obligations. Long term commits, paid up licenses, exit clauses.
4. Technical debt cost. Estimate effort to address the top three risks.
5. Integration cost if this is an acquisition. People, infra, time.

Phase 7: Synthesize and deliver (Days 17 to 20)

The deliverable is the part the deal team will actually read.

1. Executive summary in plain language. Three to five paragraphs.
2. Risk register. Each risk has a description, likelihood, impact, and recommended mitigation.
3. Findings by category. Architecture, operations, security, team, cost.
4. Recommendations. Conditions for proceeding, post close priorities, walkaway triggers.
5. Appendices. Detailed technical findings, interview notes, evidence.

Write the report assuming the reader has thirty minutes. The summary and risk register are the core. Everything else supports them.

What good looks like

A clean diligence does not mean no risks. It means the risks are known, priced, and acceptable to the deal thesis. Every meaningful technical asset has skeletons. The question is whether you can see them clearly enough to decide.

If you need someone to lead this work for an upcoming deal, this is exactly the kind of engagement I take on under technical due diligence and advisory. Get in touch if it is helpful.

References

• Y Combinator: Founder Guide to Diligence
• OWASP Top 10
• Google SRE Book
• AICPA SOC 2