Inside a Technical Due Diligence: The 8-Category Framework I Use for VC Clients

Technical due diligence is one of the more opaque parts of the startup world. Founders know it happens. Investors know it happens. Most people on both sides have only a vague idea of what the person running the diligence actually does all day, and the reports that come out of the process are usually either so generic they say nothing or so technical they are unreadable to anyone outside engineering.

This article is the version I wish someone had handed me when I started doing technical due diligence on behalf of VCs and acquirers. It is the eight-category framework I use, the specific questions I ask in each, and the patterns that kill deals. If you are a founder anticipating a diligence, reading this will let you prepare. If you are an investor trying to understand what you are paying for, reading this will let you ask sharper questions of whoever you hire.

What a technical due diligence actually is

A technical due diligence is a 1–3 week engagement where an independent technical expert evaluates a target company's technology and engineering organization on behalf of an investor or acquirer. The output is a written report — usually 10–30 pages — that answers two questions:

Are there technical risks in this deal that the investor or acquirer should know about?
Is the engineering organization capable of delivering the business case in the investment thesis?

Good diligences are specific, honest, and actionable. They do not produce scores. They produce findings, each with a severity rating and a clear recommendation. A great diligence is usable by both the investor making the decision and, later, by the company itself.

The eight categories

I evaluate every target company against the same eight categories. The framework is deliberately exhaustive — it is easier to say "this category is fine, moving on" than it is to remember a category you forgot. Here they are in the order I cover them in the report.

1. Architecture and technical foundations

What I evaluate: The overall shape of the system. How the major components fit together. The data model. The choices made about synchronous vs. asynchronous, monolith vs. services, shared vs. separated concerns. Whether the architecture is appropriate for the business stage and the scaling path.

Key questions: Is the architecture aligned with where the business is going in the next 18 months? Are there architectural decisions that will become expensive to reverse? Is the complexity justified by the problem, or has the team over-engineered?

Red flags: Premature microservices at a 5-engineer company. A monolith at 40 engineers with no internal modularity. Data models that cannot handle multi-tenancy when the business is selling to enterprises. Synchronous coupling between services that should be independent.

2. Code quality and maintainability

What I evaluate: Reading the actual code — not just statistics. Coherence, consistency, readability, test coverage, error handling, logging, the presence or absence of load-bearing weirdness. Whether a new engineer could reasonably be productive within a few weeks.

Key questions: How long would it take a senior engineer who does not know this codebase to be productive in it? Are there modules that only one person understands? Is the code a liability or an asset?

Red flags: "Don't touch this file" comments. Large sections without tests. Duplicated core logic across the codebase. Commented-out code. Magic constants without names. Silent exception handling everywhere.

3. Infrastructure, deployment, and operations

What I evaluate: How the product gets from a developer's laptop to production. CI/CD maturity. Deployment frequency. Rollback capability. Environment parity. Infrastructure as code. Disaster recovery posture.

Key questions: How often do they deploy? How long does it take to roll back a bad change? How long would it take to recover from a complete cloud outage? Is there a runbook for incidents?

Red flags: Deployments that take hours or involve manual steps. No rollback capability beyond "redeploy the previous commit and pray." No disaster recovery plan. Infrastructure configured by hand in the cloud console with no code backing it.

4. Security and compliance posture

What I evaluate: Authentication, authorization, secrets management, dependency scanning, SAST/DAST if applicable, SOC 2 or ISO 27001 status, penetration test history, incident history, encryption at rest and in transit, PII handling.

Key questions: Are the basics in place? Is there any evidence of a past incident? What is the exposure if a single engineer's laptop is compromised? Do they have the security maturity needed for their customer segment?

Red flags: Secrets in the repository. No MFA on admin access. No audit logging. No dependency scanning. A past breach that was not disclosed. Promising enterprise customers SOC 2 with no plan to actually get it.

5. Data and AI

This category did not exist in a serious way in diligence frameworks five years ago. In 2026 it is often the single most important category in the report.

What I evaluate: Data provenance and rights. Data quality. AI model dependencies — what they use, from whom, and under what terms. Fine-tuning or training data lineage. Eval infrastructure. Cost curves on AI features. Defensibility of any AI-related moats the company claims.

Key questions: If OpenAI or Anthropic changes their pricing tomorrow, what happens to gross margin? If a customer asks whether their data trained a model, can the company answer with confidence? Is there any proprietary data advantage, or is the AI layer purely a wrapper?

Red flags: AI features with no eval infrastructure. Customer data accidentally sent to vendors without appropriate terms. Claims of proprietary models that turn out to be thin prompt-engineering wrappers. LLM cost curves that will swamp margins at the next growth milestone.

6. Team and organization

What I evaluate: Who the engineers are. Experience level, tenure, role clarity, hiring pipeline. Whether the team can execute the roadmap. Whether there are dangerous single-point-of-failure individuals. Leadership strength.

Key questions: How many engineers are there, and what is the senior-to-junior ratio? Who would be the biggest loss if they left tomorrow? How fast is the team growing, and is it growing faster than it can onboard?

Red flags: One engineer who wrote 70% of the codebase and is still the only person who understands half of it. A team growing faster than its ability to maintain culture and quality. Leadership gaps (no lead, no manager, no CTO). High turnover in the last 12 months.

7. Roadmap, process, and delivery

What I evaluate: How the team plans and ships work. Cadence. Backlog health. Alignment between what the team is working on and what the business needs. Evidence of process maturity appropriate for the stage.

Key questions: Is the roadmap real, or is it a slide? Does the team hit its commitments? What is the deployment frequency, lead time, change failure rate, and MTTR? How much time is spent on features versus tech debt versus incidents?

Red flags: A roadmap that has not changed in 9 months. Sprints that routinely miss. No DORA metrics or similar. A team mostly firefighting instead of shipping planned work.

8. Strategic technical risk

What I evaluate: The one or two technical risks that would materially affect the investment thesis. These are usually the things that keep the founder up at night and the things the diligence report needs to be explicit about.

Key questions: What is the one thing in this company's technology that, if it went wrong, would most threaten the business case? Is there a risk we have not yet discussed that would change my recommendation?

Red flags: Single-customer dependencies on a vendor that is about to change terms. Regulatory exposure the team has not yet internalized. Pending open source license issues. A key engineer actively interviewing elsewhere.

How the engagement runs

A typical technical due diligence at my practice runs 2 weeks and has the following shape:

Days 1–3: Kickoff and document review. I meet the founder, agree on scope, collect every document the company is willing to share (architecture diagrams, incident history, security documentation, hiring plans, financial model for engineering cost), and start reading.

Days 4–8: Codebase review and team interviews. I read the actual code. I interview the CTO or engineering lead, 2–4 engineers, and sometimes the founder separately. I run through each of the eight categories specifically.

Days 9–11: Deeper dives and validation. Wherever I have found something concerning, I dig in. I verify claims. I sanity-check numbers. I re-interview people if needed.

Days 12–14: Report writing and debrief. I write the report — findings, severity, recommendations — and debrief the investor. Sometimes the founder is part of the debrief, sometimes not, depending on the deal structure.

The report itself is usually 15–25 pages, organized by the eight categories, with a one-page executive summary at the top.

What kills deals

Not every finding kills a deal. Most findings are "here is a risk, here is what to do about it, here is how much it will cost." A few categories of findings, though, do actually kill deals in my experience.

Security incidents the team did not disclose. Anything the team hid is the worst possible signal in a diligence. Investors can forgive a past breach. They cannot forgive being lied to about one.

Fundamentally broken unit economics driven by infrastructure or AI cost. If the business as described requires infrastructure that would cost 60% of revenue at scale, the business case is wrong. These findings sometimes reshape the deal rather than killing it, but they always matter.

A single engineer holding the company together. If one person leaving would halt the company for three months, the investor is underwriting that person, not the company. Sometimes this is acceptable with a retention plan. Sometimes it is not.

Architecture that cannot support the business case. A consumer product architecture being sold as an enterprise product. A monolith that cannot support the multi-tenancy the customer pipeline requires. These are expensive to unwind and they usually catch deals late in the process.

Counterpoint: diligence is not a grade

A technical diligence is not a pass/fail or a score out of 10. It is a map of risks and a set of recommendations. The best diligences I have seen are ones where the investor and the founder both learn something new and leave the process with an actionable to-do list, regardless of whether the deal closes.

If your diligence comes back as a single word ("good" or "bad"), it was done badly. Ask for more.

Your next step

If you are a founder about to go through a technical diligence, read the eight categories above and self-score your company honestly. Wherever you know there is a weakness, get ahead of it — document the plan, not just the problem. Diligence reports are much kinder to companies that are visibly aware of their own issues than to companies that pretend there are none.

If you are an investor considering hiring someone to run a diligence, ask them to walk you through their framework. If they do not have one, pass. A diligence without a framework is just opinions.

Where I come in

I run technical due diligences on behalf of VCs, acquirers, and occasionally founders doing outbound M&A. The engagement is time-bounded, the scope is clear, and the deliverable is a report that holds up under scrutiny. Book a call if you are evaluating a deal and want an honest independent read on the target company's technology.