Field Notes · Technical Diligence August 21, 2026 · 5 min read

Technical due diligence should test the investment thesis, not merely the technology.

A technology assessment answers whether the systems are good. A transaction needs a different question answered: whether the technical facts support the specific economic bet being priced. Those questions overlap less than deal teams assume. Excellent technology can fail a growth thesis, and unremarkable technology can support a strong one. The method that closes the gap is decomposition: convert the thesis into its technical assumptions, rank them by valuation sensitivity, and spend the diligence window on the assumptions doing the most work.

Two different questions

Standard technical diligence is organized by domain: architecture, code quality, security posture, infrastructure, team, development process. Each domain gets examined, rated, and reported, typically with a red-amber-green summary. The output answers a real question, "is this a well-built technology organization?", and it answers it in a form that is largely independent of the deal. The same report could accompany any transaction involving the same company.

That independence is the problem. An investment thesis is a specific causal claim: this company will grow revenue this way, expand margin this way, integrate with our platform this way, and is therefore worth this price. Every one of those causal claims rests on technical assumptions, and the assumptions differ by deal. The domain report can be accurate in every cell and still never examine the assumption on which the valuation actually depends, because no domain checklist contains the question "does the architecture support the margin model in the sponsor's deck?"

What thesis-coupled technical questions look like

The coupling becomes concrete the moment a thesis is stated precisely. Consider the common ones:

• A margin-expansion thesis assumes the infrastructure cost curve flattens as revenue grows. That is a technical claim about architecture: whether unit costs actually decline with scale, or whether the current gross margin is a snapshot taken before committed-capacity discounts expire, before the data volume forces a storage-tier change, or before the workloads that are currently subsidized by underpriced usage get repriced by the cloud vendor.
• A growth thesis assumes the platform reaches the projected user or transaction volume without a step-change rebuild. Whether scaling is a matter of paying for more capacity or re-architecting the data layer is discoverable in diligence, and the two answers imply different capital plans and different timelines.
• A platform or synergy thesis assumes integration: shared identity, compatible data models, APIs that expose what the acquirer needs. Integration cost is routinely the largest post-close technical surprise, and it is estimable in advance if someone examines the actual interfaces rather than the marketing architecture diagram.
• A proprietary-AI thesis assumes the company owns something defensible. What exists is discoverable: trained assets the company holds rights to, data with documented provenance and usable rights, or a thin orchestration layer over third-party models that any competitor could reproduce in a quarter. These are different assets at different prices, sold under the same adjective.
• A continuity thesis, implicit in every deal, assumes the systems keep running through ownership change. Key-person concentration, undocumented operational knowledge, and expiring third-party agreements are technical facts with direct retention-package and escrow implications.

In each case the deal-relevant finding is not "the technology is good or bad." It is "this specific assumption, which carries this much of the valuation, is supported, unsupported, or purchasable at a knowable cost."

The method: decompose, rank, test

The discipline is straightforward to state and requires access to the thesis, which is the first practical change: the technical diligence team must be given the investment thesis, not just the data room. From there:

1. Decompose. Extract from the thesis every claim that depends on a technical fact: cost curves, scaling behavior, integration surfaces, ownership of claimed assets, continuity dependencies, security posture material to the customer base being purchased.
2. Rank by valuation sensitivity. Ask of each assumption: if this proved false, what happens to price, timing, or the deal itself? Assumptions whose failure re-prices the transaction get the diligence hours. Assumptions whose failure costs an annoyance get noted and sampled.
3. Test the top of the list. Testing means evidence: measured infrastructure economics rather than the model's assumptions, load behavior rather than the roadmap's assurance, actual API and data-model inspection rather than the integration slide, artifact-level verification of claimed AI assets. Where a claim cannot be verified in the window, that is recorded as an open assumption, not silently promoted to a finding of health.
4. Report in thesis terms. Findings land as: supports the assumption; breaks the assumption; re-prices the assumption (with the estimated cost or delay); or cannot be determined pre-close (with what would resolve it and when). An investment committee can act on every one of those sentences. It cannot act on "security: amber."

The floor still exists

None of this retires the domain review, and the strongest objection to thesis-led diligence deserves its answer here: some technical facts matter regardless of thesis. Evidence of existing compromise, license contamination in the codebase, disputed IP provenance, and material security exposure in the customer-facing product are deal-relevant in every transaction, because they change what is being bought at all. The domain checklist is the floor that catches them, and the floor is genuinely necessary. The argument is about where judgment and hours above the floor go: a diligence budget spent evenly across domains is a budget allocated by template rather than by the deal, and the questions that carry the valuation are, by default, the ones examined most shallowly.

A second boundary condition: thesis-led diligence requires an actual thesis. In early-stage investing, where the bet is substantially on team and market rather than on present systems, the technical assumptions are thinner and the method degrades gracefully into a smaller exercise. It is mid-market and later transactions, where the model carries specific operational and cost claims, where the gap between technology review and thesis review is widest and most expensive.

Why independence matters here specifically

Diligence late in a deal operates inside momentum. The sponsor has committed attention and reputation; management wants the transaction; advisers are compensated on close. In that environment, a domain-checklist review is comfortable precisely because its findings are rarely deal-shaped: amber cells prompt remediation budgets, not re-pricing. Thesis-coupled findings are deal-shaped by construction, which is why they are worth commissioning and why they are best produced by someone whose economics do not depend on the outcome. The evidentiary posture is the same one that governs investigations: state what was verified, state what could not be, and refuse to let the unexamined default to "fine."

Conclusion

A transaction prices a story about the future, and part of that story is always technical. Diligence that evaluates the technology in general answers a question adjacent to the one the capital is asking. The correction is procedural: hand the technical team the thesis, decompose it into assumptions, rank the assumptions by what their failure would cost, test the expensive ones against evidence, and report in the currency the investment committee actually spends: price, timing, conditions, and unknowns.

Related: A Technical Claim Is Not Evidence, on converting labels like "proprietary AI" and "enterprise ready" into testable statements.

← All Field Notes