Technical diligence should be a product, not a consulting practice.

01The unevaluated asset

When capital changes hands in a software deal, the thing actually being bought is a codebase. Not the ARR schedule, not the customer list; those are consequences. The code is what produces them, and it is the one asset in the transaction that nobody in the room can read.

Financial diligence has a playbook. Legal has one. Commercial has one. Technical diligence has a phone number for a consultant, a three-week window, and a sampling strategy. The result is that the risk categories which recur most reliably across software transactions are also the ones most reliably left unpriced.

Read those together and the shape of the problem is clear. This is not a market that doubts the value of technical diligence. It is a market that cannot afford to run it.

02Why the current model can't close the gap

The gap persists because of arithmetic, not ignorance. An enterprise consultancy bills $200–$800 an hour and delivers over months. A mid-market boutique charges $40K–$100K over three to four weeks. Both are priced per engagement and gated by the availability of a specific senior practitioner.

That produces three structural failures, none of which more spending fixes:

It cannot run early. At $40K a look, diligence runs on the deal you have already decided to do. The screening decision, the one that determines which deals you pursue at all, is made without it.

It cannot run repeatedly. A snapshot ages. By the time a continuation vehicle or a secondary transaction prices an asset, the original assessment is three to five years stale, the codebase has turned over, and the engineering team may have too.

It cannot run consistently. Output quality tracks the individual assigned. Two engagements at the same firm produce materially different reports, which is why coverage is rarely end-to-end and why findings are hard to compare across a portfolio.

03What breaks when the cost curve collapses

Take the same eleven-module assessment and move it from three weeks and $60K to a few hours at a fraction of the cost, and the change is not that firms get the same report faster. The change is that the report becomes a different instrument.

Diligence becomes screening. If assessment is cheap enough to run pre-LOI, it runs on targets you would never have resourced. A firm looking at forty deals a year is suddenly making technical judgements on all forty rather than the eight that reached exclusivity. That is not a speed improvement; it is a wider field of view.

Diligence becomes monitoring. The same engine re-run on a schedule through the hold period tracks debt accumulation, security drift and technical covenant signals. In credit, that is an early-warning system that does not currently exist in any form.

Diligence becomes preparation. Run from the sell side twelve months out, the identical assessment surfaces what a buyer's diligence would surface, while remediation is still a sprint rather than a re-trade. Repeated quarterly, it produces a documented history of technical governance, which is an asset in a negotiation, not just a file.

One engine, four moments in the life of an asset. The unit of value shifts from a report commissioned on one deal to an intelligence layer running across a pipeline and a portfolio.

04Where it applies

The same assessment addresses seven distinct buyers. They differ in what they are underwriting, not in what needs to be examined.

05Why a product wins, and what it has to get right

Automation alone is not the thesis. Code scanners have existed for twenty years; they lose because they are sold to engineering teams to fix code, not to investors to price it. Their output is a backlog. An investment committee cannot read a backlog.

Three things have to be true for a product to displace the practice:

The output has to be investor-grade. Technical condition translated into business consequence, remediation cost in engineering months, and transaction relevance. A finding that a deal team cannot act on is not a finding.

The analysis has to be reconciled, not parallel. Eleven modules producing eleven reports is eleven times the noise. Key-person concentration reads differently alongside three in-flight migrations; licensing exposure changes meaning next to an AI roadmap. The findings that move deals are cross-module, and they only appear if the modules are read against each other.

The target has to be able to say yes. This is the real gate. No portfolio company hands its source code to a third-party vendor because a prospective buyer asked. Any product that requires it is capped at the deals where the target has no leverage, which is not the deals worth doing.

That is why the architecture is the go-to-market. An attested, ephemeral, single-tenant environment the target authorises and can revoke, where we receive the findings and never the repository, is not a security feature bolted onto a product. It is the thing that makes the product deployable across a portfolio at all.

06What we are building

An assessment engine that reads a target's entire codebase across eleven modules, reconciles the findings against each other, subjects every conclusion to an independent critic pass, and returns an investor-grade report in hours, inside an environment the target controls and we cannot enter.

The models behind the modules are fine-tuned on completed diligence assessments and the outcomes of the deals they informed. That is the difference between a finding a deal team can price and an entry in an engineering backlog, and it is not something a general-purpose scanner or a general-purpose model arrives at on its own.

The first proof is a complete assessment of a large, public production codebase of 44,499 commits, 552 contributors and 1.23M lines, run across all eleven modules, with every finding carrying evidence references and a remediation estimate. It is the same output a deal team would receive inside an exclusivity window.