How VCs Read a Technical Company

Technical due diligence is an evidence review, not a vision test. The failures that cost the most money were visible in the architecture diagram and the org chart months before anyone signed a term sheet.

I get asked to look at software companies from both sides of the table. Sometimes a founder is preparing to raise or sell and wants to know what a technical reviewer will find. Sometimes a buyer has already found something and wants a second opinion on how bad it is. The questions I ask are the same in both cases, and they are almost never about the pitch.

The arithmetic explains why. Gompers, Gornall, Kaplan and Strebulaev surveyed venture capitalists about how they decide. A firm reviewed more than 100 opportunities for each deal it closed, and the closed deal took 83 days, 118 hours of due diligence and ten reference calls (NBER Working Paper 27824, September 2020). Subtract the financial and legal work, and the person looking at the technology has days, not weeks. That person cannot audit a codebase. They can request artifacts, check two of them against each other, and notice which ones do not exist.

What diligence is buying

Diligence does not produce certainty. Of more than 21,000 venture financings tracked by Correlation Ventures, 65% returned less than the capital invested and 4% returned ten times or more, as Seth Levine reported in August 2014. A process that spends 118 hours per deal exists to avoid the losses that were knowable at the time, because those are the ones a partner has to explain to their own investors.

That reframing matters for the operator on the other side. The question is whether the things that would destroy the company are absent, insured, or priced into the deal. Evidence is whatever still exists when you are not in the room: the commit history, the incident tickets, the cloud invoice, the customer contracts, the signed assignment agreements. Adjectives are not evidence.

Start with the architecture, and with who can draw it

Ask for a one-page diagram of the production system dated within the last ninety days. Then ask the engineer who carries the pager to draw the same system on a whiteboard without looking at it. Where the two drawings disagree is the finding. A CTO’s diagram is usually a sales asset. The pager-holder’s diagram is the system.

On that page I want the services, the data stores, the trust boundaries between them, where credentials live, and what stops working when the identity provider is unavailable. I want to know how a new environment gets built and how long it takes, because the answer separates a company from a pile of scripts. The most useful question is what the last significant infrastructure change cost in engineering hours, and who paid for it.

The failure this prevents shows up in the integration plan two weeks after close. “Everything is containerized” and “we could move clouds in a quarter” are checkable claims. Look at what is containerized, find what still runs on a virtual machine someone built in 2019 and patches by hand, and read the runbook for the system with no owner. Architecture debt is the invoice for the first change the new owner wants to make.

The dependency list is the risk register

CrowdStrike’s external root cause analysis from August 2024 reads best as a document about dependencies. A new template type declared 21 input fields. The integration code that invoked it supplied 20. The content validator assumed 21 and passed the malformed instance downstream, where Windows sensors crashed. The mismatch survived build validation and several layers of testing. The customers did nothing wrong; they had installed a security agent and it took their fleets down.

The question that follows is which vendors can change your uptime or your unit economics without your consent, and what you have tested.

Build a register of everything that can change on someone else’s schedule: cloud region, identity provider, payment processor, email, the model provider behind any AI feature, open-source projects with a single maintainer, and licenses that renew at a price you did not negotiate. For each row, write what breaks, what the fallback is, and whether anyone has exercised the fallback. Three tested fallbacks beat thirty theoretical ones, and the register itself is the artifact a reviewer will ask to keep.

AI features need their own row now. A model deprecation, a rate limit, or a price change lands on the roadmap and the gross margin in the same week, and the provider’s terms usually permit it. If the product’s differentiation is a prompt sent to someone else’s API, that is a margin question before it is a technology question. The same logic runs inside the company: AI adoption is a workflow problem, and the workflow debt is visible in the repository long before it reaches the P&L.

Incident history, and whether the cause repeats

Ask for twelve months of incidents with severity, duration, cause and the change that closed them. Then take the three worst and read the postmortems. One bad night is normal. The same root cause in February and September is a management finding, and it will still be there after the deal closes.

Ask separately about personal data. Every state now has a breach notification law (NCSL, updated December 2025), so an incident that stayed quiet in one jurisdiction can still carry obligations in another. IBM’s 2026 Cost of a Data Breach report puts the global average at $4.99 million across 602 organizations breached between March 2025 and February 2026, with malicious breaches that used AI averaging $6 million (IBM, 29 July 2026). I do not put that average into a small company’s model; averages hide the distribution. I use the figure to price the tail, and to explain why an unreported incident is a liability that travels with the equity.

Two more artifacts belong here: the cyber insurance policy with its limits and exclusions, and the claims history. An underwriter has already examined the controls, and their exclusions tell you what they consider likely. Patching evidence should be measured against the CISA catalog of known exploited vulnerabilities, as of publication, rather than a vendor score, because that list is what attackers actually use.

Customer concentration is a technical fact

Sales treats concentration as a revenue topic. It shows up in the technology. One customer’s integration shapes the data model, one customer’s service level sets the on-call rota, and one renewal date decides whether the company has a business next year. Public companies disclose a customer once it crosses 10% of revenue, and the disclosures are blunt about how high that gets: Lumentum’s fiscal 2025 annual report lists two customers at 16.0% and 15.4% of net revenue.

I use the same number for private companies. A customer above 10% of revenue turns diligence from “does the product work” into “what happens at renewal.” Ask for the top five contracts, the term and termination clauses, the renewal dates, and the depth of each integration. Then ask who owns the relationship and whether that person is staying through the transition.

Concentration hides elsewhere and deserves the same treatment: one reseller or channel partner, one geography, one regulator, one upstream supplier whose price is your cost of goods.

Tests, deploys, and the claim of velocity

Do not ask whether the team writes tests. Ask for the CI configuration, the last twenty production deploys, the change failure rate for the quarter, the time to restore service, and a rollback that actually happened. Ask who is on call this week and what the escalation path looks like at 3 a.m. Teams that deploy often have this data because they need it. Teams that deploy quarterly have a narrative instead.

AI has changed the shape of this question. DORA’s 2025 research, drawn from nearly 5,000 respondents, found that 90% use AI in their work, 30% report little or no trust in the code it produces, and adoption improves throughput while increasing delivery instability. For a reviewer, the question is whether the delivery system absorbs the variance: tests that fail loudly, review that reads generated code, and a pipeline that can be reversed in minutes.

Key people, and who owns the code

Ask who can deploy to production on a Sunday, who holds the root credentials, and what happens in the two weeks after the person who understands the billing system leaves. A company where one engineer is the deployment pipeline has an uninsured single point of failure. The fix is a named decision right, and a small company needs one accountable owner rather than a committee.

Then comes ownership, where the cheap mistakes hide. Code written by a contractor is not automatically yours. Under 17 U.S.C. §101, a commissioned work counts as a work made for hire only for enumerated categories and only where the parties agree in a signed writing. If the assignment agreement does not exist, the finding is that the company licenses its own product from a former contractor.

Two more rows belong here. First, an open-source inventory with the licenses that carry obligations, especially the ones that reach into a hosted product. Second, provenance for AI-assisted work: the Copyright Office’s January 2025 report concluded that prompts alone do not give a user enough control to be treated as the author of the output. Code and content produced that way can be useful and still not be ownable. That is a valuation input, not a legal footnote.

The scorecard I use

Eight dimensions, each scored 0 for no artifact, 1 for an artifact with gaps, and 2 for an artifact that a second source confirms. The two lowest rows set the price, the escrow, or the warranty, and they set the first hundred days.

Dimension	Evidence I ask for	Failure it prevents	What a zero looks like
Architecture	One-page production diagram dated within 90 days, corrected by the on-call engineer	Migration and integration cost discovered after close	No diagram, or one that predates the last platform change
Dependencies	Register of vendors, model providers and licenses, with a tested fallback for the top three	An outage or price change you cannot control	A vendor list that omits the model provider
Incidents	Twelve months of tickets, plus postmortems for the three worst	A root cause that repeats after the deal	“We don’t really have incidents”
Data and notification	Data map, breach history, cyber policy and claims record	Undisclosed notification liability	No inventory of where personal data lives
Concentration	Top five contracts with terms, renewals and integration depth	A revenue cliff at renewal	The largest customer’s revenue share is unknown
Delivery	CI configuration, twenty deploys, change failure rate, one completed rollback	Velocity claims that fail in a bad month	Nobody can produce a deploy log
Key people	Deploy rights, credential holders, a named successor for each critical system	An uninsured single point of failure	One person can deploy and nobody else can
Ownership	Signed assignments, open-source inventory, AI provenance note	An asset the company does not own	Contractor agreements with no IP clause

What this means for operators

These artifacts serve three audiences with one body of work. A customer’s security questionnaire asks for most of them, a cyber insurance renewal asks for the rest, and a financing or a sale asks for all of it in a week. The underlying work is the same; only the framing changes. A company that can produce the set on request is worth more than an identical company that needs six weeks, because buyers pay for certainty and the absence of records reads as risk.

That is also why the review is unkind to good engineers. A team can build a solid system and still fail the review, because three people hold the operational knowledge and the supporting evidence sits in a Slack thread. The leadership question underneath is decision rights: who is accountable for the diagram being true, who signs the vendor that becomes a dependency, and who decides that a renewal risk is worth a second product line.

If you are the subject of a review, the cheapest time to build the evidence room is the quarter before anyone asks. If you are the buyer, ask for artifacts and let the seller’s inability to produce them be the answer. Both directions reward the same habit: keep records while nothing is at stake.

What to do

1. Draw the production diagram this month. One page, every external dependency, dated. Have the on-call engineer correct it, and keep the corrected version wherever the runbooks live.
2. Build the dependency register and test one fallback. Include model providers and single-maintainer libraries. A fallback nobody has run is a hypothesis, not a control.
3. Keep a twelve-month incident log. Severity, duration, cause, fix. Write a short postmortem for anything that lasted more than an hour, and check whether the same cause appears twice.
4. Measure concentration before someone asks. Top five customers and top three channels by revenue, with renewal dates and termination terms in the same table.
5. Record four delivery numbers quarterly. Deploy frequency, change failure rate, time to restore, and the date of the last rollback. Trends matter more than any single month.
6. Paper the ownership. A signed assignment for every contractor, an open-source inventory with the licenses that carry obligations, and a note on which code was AI-generated.
7. Score yourself against the table every quarter. Fix the two lowest rows before the next raise, sale, or enterprise security review rather than during it.

This quarter, the decision is whether your company has an evidence room or a story. Pick the two rows you would score zero on today, build those artifacts, and keep building them while the stakes are low. The artifacts cost engineering time. Their absence costs money at the worst possible moment.

Sources

1. Venture Capitalists and COVID-19 — National Bureau of Economic Research, 2020-09.
2. Venture Outcomes are Even More Skewed Than You Think — Seth Levine, 2014-08-12.
3. External Technical Root Cause Analysis — Channel File 291 — CrowdStrike, 2024-08-06.
4. Security Breach Notification Laws — National Conference of State Legislatures, updated 2025-12-15.
5. IBM Study: One in Four Malicious Breaches are AI-Enabled, Costing Companies $6 Million on Average — IBM, 2026-07-29.
6. Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency, accessed 2026-10-06.
7. Form 10-K for the fiscal year ended June 28, 2025 — Lumentum Holdings, 2025-08-19.
8. State of AI-assisted Software Development 2025 — DORA / Google Cloud, 2025-09-23.
9. 17 U.S.C. §101: Definitions — Legal Information Institute, Cornell Law School, accessed 2026-10-06.
10. Copyright and Artificial Intelligence, Part 2: Copyrightability — U.S. Copyright Office, January 2025.