Technical Due Diligence: What VCs Actually Look At

You are raising a Series A or Series B. The lead investor says they want to do "technical due diligence." They hire a technical advisor (usually a former CTO) who spends 2-4 hours interviewing your team, reviewing your codebase, and assessing your infrastructure. Their report can make or break the deal.

Here is exactly what they look at and how to prepare.

What technical DD evaluates

Technical due diligence answers one question: can this team build and scale the product with the capital we are investing? The evaluation covers six areas.

1. Architecture and scalability. The reviewer looks at your system architecture diagram (you should have one). They want to understand: Is the architecture appropriate for your current scale? Can it handle 10x growth? Are there single points of failure? Is the system modular enough to evolve as requirements change?

What impresses: clear architecture documentation, defined service boundaries, a database that is not at 80% capacity, and evidence that you have thought about scaling before being forced to.

Red flags: no architecture diagram, a monolith with no module boundaries, a single database that is already struggling, and "we will figure out scaling when we get there."

2. Code quality and development practices. They will pull up your repository and look at recent commits, PR reviews, test coverage, and code organization. They are not reading every line. They are sampling to assess the overall quality.

What impresses: consistent code style, meaningful PR descriptions, thorough code reviews, test coverage above 60%, and a CI pipeline that runs tests on every commit.

Red flags: no tests, PRs merged without review, inconsistent code style, and large commits with no description.

3. Infrastructure and operations. How is the application deployed? How is it monitored? What happens when things break?

What impresses: infrastructure as code (Terraform), automated deployments, monitoring dashboards, alerting with on-call rotation, and documented runbooks.

Red flags: manual deployments, no monitoring, no alerting, and "our CTO SSHs into the server when something breaks."

4. Security. Do you have basic security controls in place? This is not a full security audit. It is a smell test.

What impresses: SOC 2 compliance (or progress toward it), MFA everywhere, encrypted data at rest and in transit, dependency scanning, and a security incident response plan.

Red flags: no encryption, hardcoded secrets in code, no access controls, and "we have not thought about security yet."

5. Team and organization. Is the team structured for growth? Are the right people in the right roles?

What impresses: clear reporting structure, defined engineering levels, a mix of senior and junior engineers, low turnover, and a healthy engineering culture.

Red flags: flat organization with no structure, all junior engineers, high turnover, and a single person who is a bottleneck for all decisions.

6. Technical debt and risks. Every codebase has technical debt. The question is whether you know about it and have a plan for managing it.

What impresses: a documented list of known technical debt, a plan for addressing high-priority items, and evidence that you allocate engineering time to debt reduction.

Red flags: denial that technical debt exists, a backlog of critical bugs, and a team that is afraid to touch large parts of the codebase.

How to prepare

One month before DD, prepare these artifacts:

• Architecture diagram (current state and planned evolution)
• Development process documentation (how code goes from idea to production)
• Infrastructure overview (cloud resources, monitoring, alerting, backup)
• Security summary (controls in place, compliance status, recent pentest results)
• Team org chart with roles and levels
• Technical debt inventory with prioritization
• Key metrics: deployment frequency, uptime, test coverage, mean time to recovery

Do not fabricate anything. Experienced technical reviewers will see through it immediately. If you have gaps, acknowledge them and present your plan for closing them. Honesty about weaknesses is much better than pretending they do not exist. If you want an outside read on where the gaps actually are before the investor finds them, that is a normal fractional CISO engagement.

How the process actually runs

Knowing the six areas matters less than knowing the shape of the week, because most of the damage in technical DD is done by process mistakes rather than by genuine technical weakness.

It starts with a document request, usually sent by the associate rather than the technical advisor, and usually broader than what will actually be read. Then a two to three hour session with your CTO covering architecture and roadmap. Then shorter sessions with two or three engineers chosen by the reviewer, not by you, which is the part founders underestimate. Then a code and repository walkthrough, sometimes read-only access for a day, sometimes screen sharing while an engineer navigates. Then a written report to the investment committee, typically five to fifteen pages, that you will never see in full.

The engineer sessions are where positions come apart. A reviewer asks the same question of the CTO and of a senior engineer, and the interesting output is the delta. If the CTO says deployments are automated and the engineer says they are automated except for the migration step that someone runs by hand, the reviewer does not conclude that your deployments are bad. They conclude that the CTO's picture of the system is out of date, which is a much more serious finding and one that colors everything else in the report. Brief your team on the same facts you briefed the investor with, and if any of those facts are aspirational, correct them before the session rather than after.

Timing is the other process trap. Technical DD normally runs after the term sheet and inside a thirty to forty-five day exclusivity period, alongside financial and legal diligence, while your team is also trying to hit the quarter. Whatever preparation you have not done by term sheet is preparation you will be doing at nights.

The questions that separate a clean report from a hedged one

Experienced reviewers do not work from the checklist you would expect. They ask a small number of questions designed to reveal how the team behaves under pressure.

Walk me through your last production incident. This is the single highest-yield question in technical DD. It tests monitoring (how did you find out), process (who was paged and what did they do), architecture (what failed and why was the blast radius that size), and culture (what changed afterwards, and did anyone get blamed). A team with a written postmortem and a completed action item list answers it in five minutes and clears four checklist areas at once. A team that says nothing has gone wrong recently is either lucky, new, or not looking.

What would you rebuild if you had three months and no feature pressure. The reviewer is testing self-awareness. A precise, prioritized answer with reasons is a strong signal. "Nothing, the architecture is solid" reads as either inexperience or evasion, and both get written down.

Who is the only person who can do X. Key-person risk is assessed regardless of whether anyone asks about it directly. If one engineer owns the billing service, the deployment pipeline and the database, that fact will emerge from the sessions on its own. It does not kill deals; it shows up as a retention condition in the documents.

Show me a pull request from last week. Not a curated one. The reviewer wants to see the ordinary case: description quality, review depth, how long it sat, whether tests ran. Two minutes of scrolling tells them more about your development practice than any document you prepared.

How does a customer's data get deleted. Deceptively narrow, and it forces you to trace data through every system: the primary database, the analytics warehouse, the search index, the backups, the third-party tools, the log platform. Most teams discover during this answer that they do not know all the places customer data lands, which is both a diligence finding and a privacy problem under PIPEDA and Quebec Law 25.

What has been added to the security section since 2023

The security portion of technical DD used to be the smell test the article above describes. For any company selling to enterprises, it has grown teeth, mostly because the investor's own limited partners and the eventual acquirer both care.

Expect specific asks. Your SOC 2 report or your dated plan to obtain one, with the observation window named. Your most recent penetration test report, including the remediation status of every finding rather than just the executive summary. A subprocessor list, meaning every third party that touches customer data, which is also what your customers' contracts require you to publish. Your data retention and deletion positions. Evidence that access to production is restricted and reviewed. An incident history, including the incidents that did not require notification.

Two newer areas catch teams out. The first is AI. If your product uses a model provider, expect questions about what customer data is sent, whether it is used for training, what your data processing agreement with the provider says, and what happens when the model returns something harmful. If you use models to process regulated data, that is a contractual and regulatory question, not just an architectural one. The second is open source licensing. A reviewer will run a dependency license scan, and a copyleft license sitting inside a distributed component is the kind of finding that goes to the lawyers and stays in the deal documents. Run that scan on yourself first; the tooling is free and takes an afternoon.

The order that reads best is a report in hand, then a report scheduled with an auditor engaged, then a documented readiness position with dates. All three are acceptable. "We will start when we have to" is the one that costs you. A structured readiness position has commercial value on its own, and one client used theirs to take $11,000 off an audit quote, which is a useful reminder that the document is not just for investors. Our compliance work exists to produce exactly that artifact.

Findings do not kill deals, they reprice them

Founders imagine technical DD as pass or fail. It almost never is. By the time a technical reviewer is engaged, the investor wants the deal and is looking for the price of the risk. Findings turn into terms.

A serious architecture concern becomes a milestone attached to the tranche structure, so part of the money arrives after you have addressed it. Key-person risk becomes a retention package and a founder vesting refresh. A security gap becomes a closing condition: SOC 2 observation window started within ninety days, penetration test completed and criticals closed before the second tranche. Unclear IP ownership becomes a representation and warranty with real teeth, plus a scramble to collect assignment agreements from every contractor who ever committed code. Unresolved license exposure becomes an indemnity carve-out.

That last one deserves preparation in its own right. Every contractor, every former co-founder, every agency that touched the codebase needs a signed assignment. If your first engineer built the prototype before incorporation and never signed anything, deal with it now, quietly, while the relationship is good. Finding out during exclusivity that a person who left on bad terms owns part of your product is a different conversation entirely.

The findings that genuinely end deals are small in number and consistent in character: a founder who was demonstrably untruthful about something checkable, an undisclosed breach, undisclosed litigation, or a product whose core claim does not work when someone competent looks at it. Every one of those is a disclosure failure rather than a technical failure.

Acquisition diligence is a harder exam

If the round is a step towards being acquired, understand that the same six areas get examined very differently by a buyer. A VC is underwriting whether the team can build. An acquirer is underwriting whether they can absorb the system and whether it will create liability on their balance sheet.

That changes the emphasis. Acquirers care intensely about IP chain of title, about whether your security posture will pass their internal vendor onboarding, about the licensing and privacy exposure they are inheriting, and about how many of your engineers stay. They will send more people, they will spend more days, and they will read the penetration test findings line by line rather than the summary. Several deals get their price adjusted late because the acquirer's security team refuses to onboard a system that would fail the acquirer's own controls.

The practical implication for a Series A company is modest but real: the artifacts you build for investor DD are the same artifacts an acquirer will ask for in three years, so build them in a form you can maintain rather than a form you can assemble once. A data room that is a snapshot of one week rots. An architecture document that lives in your repository next to the code, updated when the code changes, is still accurate at exit.

Running the room

Small operational choices change the outcome more than they should.

Give read-only repository access rather than screen sharing when you can, and give it to a named individual under an NDA that names them. A reviewer who can navigate on their own forms a first-hand impression, which is usually better than the impression formed while watching a nervous engineer scroll.

Answer "I do not know, I will find out by tomorrow" rather than guessing. Reviewers write down wrong answers. They do not write down deferred ones, provided the answer actually arrives.

Bring your known problems up first, with the plan attached. A reviewer who finds a weakness you disclosed records it as managed risk. The same weakness found on their own gets recorded as an unknown-unknowns problem, and unknowns get priced far more harshly than knowns.

Do not put your entire engineering team through preparation. Two people preparing while eight continue shipping produces a better quarter and a better report than ten people polishing documents, because the reviewer will also ask about velocity during the diligence period and a stalled sprint is visible in the commit history.

Keep a written log of every question asked and the answer given. Diligence questions repeat across investors, and the log becomes your starting document for the next round and for the customer security reviews that will arrive in between.

Preparation costs, and when to skip them

A mock diligence exercise is a real thing you can buy, and it is usually a week: document review, interviews with the same people the reviewer will pick, a repository and infrastructure walkthrough, and a findings list ranked by what will actually appear in a report. The output is worth having mainly for the gaps you were not aware of, since the ones you already know about you could have listed yourself.

There are clear cases where you should not buy it. If you have raised institutionally before and been through technical DD, you know the drill and your artifacts mostly exist; refresh them yourself. If you are pre-seed or raising on a SAFE from angels, there is no technical DD to prepare for, and a week spent on diagrams is a week not spent on the product that will determine whether a Series A happens at all. If your term sheet is signed and diligence starts on Monday, an outside engagement will not land in time and will compete for the same engineer hours the reviewer needs; spend the week collecting documents and briefing your team instead.

And if your gaps are known, specific and technical, buy the specific thing rather than the assessment. If the missing item is a penetration test, book the test; we run them from $1,000 depending on scope, and a test report with closed findings is worth more in a data room than any readiness memo. If the missing item is security ownership, the answer is a named owner, which a fractional CISO supplies from $3,000 a month. Paying someone to tell you what you already know is the most common waste in this category. If you are not sure which situation you are in, describe it to us and we will tell you, including when the answer is that you are ready and should save the money.