The three constraints that define the work

Every environment you have worked in gave you three things you never had to ask for: time to look properly, the actual code, and colleagues with no particular stake in your conclusion. At PayPal, at Halo, at Arrived, on your own products — the code was there, and if it took another two days to understand something, it took another two days.

Diligence removes all three at once. That is not an inconvenience wrapped around the real work; it is the work, and it is why an instrument exists at all. If you had unlimited time, full repository access and disinterested informants, you would not need a rubric. You would just read the code.

Constraint one: a clock you do not control

Start with an honest correction, because getting this wrong in an interview is worse than not knowing. It is commonly said in this territory that diligence runs in days rather than weeks. Checked against what is actually published, that is too strong — and the real picture is more useful anyway.

The published figures cluster at two to four weeks for the main engagement. One firm states two to four weeks at a fixed fee; a data-room vendor describes two to four weeks, broken into documents, code, interviews and quantification; a diligence shop says one to three weeks for most venture deals and two to six for complex acquisitions.

Where “days” is genuinely right is at the ends. Another vendor describes a pre-offer screen taking a few days, a post-offer deep dive taking two to four weeks, and a confirmatory pass taking a few days again. And one sells a five-business-day read, with a 48-to-72-hour checkpoint before the offer.

What the shape means for your instrument is concrete. There is an early moment, measured in days, where a fast structured read is exactly what is wanted — and that is where a one-page rubric with nineteen questions is a better fit than a thorough report nobody has time to commission yet. Build for that moment. A rubric that only pays off in week three is a rubric that never gets used, because by week three somebody with more deal experience than you owns the document.

Constraint two: access is negotiated, not given

This is the best-evidenced of the three, and the one people underestimate most. The bluntest statement comes from a diligence firm conceding the limits of its own product — which is worth something, given the direction the incentive points:

“The company is also unlikely to give you unfettered access to all of their code… That leaves you at the whims of the company to cherry-pick what you review, which in turn means you aren’t getting a good representative sample.” (Marty Abbott, AKF Partners, 2018 — a firm that sells technical diligence)

The staging is explicit elsewhere. Before an offer, a competitive seller guards the codebase until exclusivity, releasing an architecture overview, the stack, the hosting bill, dependency manifests, IP chain of title and a demo — but not repository access or commit history. When repository access does arrive, it is narrow: one vendor describes it as read-only for five to ten business days, for a named reviewer, under an NDA. Another describes a supervised read on the target’s own machine with nothing downloaded, and an escrow arrangement where a neutral firm reads the code and reports without the code ever reaching the buyer.

And at the far end, some diligence is run without code at all. Bain — a firm that sells technical diligence to private equity — titles a podcast episode on the subject “from the outside in”, and the page carries the pull-quote that you do not need the keys to the source code or the server farm to learn a great deal about a business. The episode itself is audio and the transcript is not published, so take that as the firm’s public positioning rather than a documented method.

The operational consequence for the instrument is the not assessed mark. It exists so that a question you could not answer stays visibly unanswered instead of being quietly rounded to amber, which is the reflex — amber feels honest, feels cautious, and is a lie, because it tells the reader you looked and found something middling. A page carrying six “not assessed” marks is telling the investment committee something true and useful about the access their own deal team negotiated.

Constraint three: the counterparty has an interest in the answer

The cleanest statement of this comes from outside the diligence trade entirely — a training publisher that sells finance courses, not diligence engagements:

“The seller knows everything about its own business and the buyer knows far less. Making matters worse, the seller is incentivized to hide or downplay negative aspects of the business and exaggerate the positives.” (Wall Street Prep, updated 2023)

This is not an accusation of dishonesty and you should not present it as one. It is a structural fact about which side of a transaction each person is standing on, and it applies to people behaving entirely in good faith. The engineering lead who walks you through the design system genuinely believes it is adopted. They have simply never had a reason to count.

The practice has industrialised around this. Sell-side technical diligence is a named, purchasable service: one firm offering it describes the point as helping a seller surface issues before buy-side diligence and eliminate potential deal killers, in service of a higher valuation. So the company you are assessing may already have been assessed, by someone hired to find exactly what you are about to look for, several months earlier, with instructions to fix or frame it.

The tells are documented from both directions. A buy-side firm says it wants engineers not selected by management, and warns that a target offering only a prepared deck and a single management interview yields a surface-level read. From the other side, the field guide written for the CTO being diligenced coaches honest communication from the engineering team rather than scripted or protected staff — advice that only needs writing because the scripted-and-protected posture is the default it is arguing against.

Which points at a rule for your rubric that is stronger than any interviewing technique: prefer evidence the seller did not choose to give you. A published changelog, the actual rendered DOM of their application, their public documentation, their job postings, their support portal, the release notes for their mobile app. None of it was curated for your visit. All of it is free. And a question that resolves against uncurated evidence survives all three constraints at once, which is the only kind of question worth keeping near the top of the page.

What this does not cover

The shape of the instrument is now settled: a reader, a conversion rule that turns findings into weeks, and three constraints that decide which questions are worth carrying. What it does not yet have is content — the actual questions under each axis, and the evidence that answers them.

That is the next module, an axis at a time. It opens with the UX maturity lesson, which is the hardest of the four to make objective and therefore the one where a badly written threshold does the most damage. After it come front-end debt, agentic readiness and graftability. Only once all four exist does the scorecard become a document rather than a list, which is the module after that.