An audit enumerates. A diligence prices.
An audit is complete and a diligence is decisive, which is why a finding with no cost and no timeline attached is not a finding at all — it is an observation you made the buyer pay for.
You have run audits before, even if nobody called them that. A component inventory across a product to find every button implementation. An accessibility sweep before a release. A dependency review after a security scare. In every one of those, the scoring function was the same: you won by finding everything, and a miss was a failure.
Diligence inverts that scoring function, and the inversion is not obvious, because the activity looks identical from the outside. Same person, same screens, same eye. The difference is that a diligence with forty true findings and no prices attached is a worse document than one with six findings and a number against each — and if you carry the audit instinct into it, you will produce the forty and feel good about it.
Completeness is the wrong virtue
The trade sources are unusually consistent on this, and worth reading with the bias in view: nearly everything published about technical due diligence is published by firms that sell it. One such firm, selling compressed reads to private equity buyers, draws the boundary in a single sentence — a technical diligence “is not a penetration test, a code-quality audit, or a vendor assessment — those are downstream activities once you own the asset”, and describes its own engagement as risk-focused and sample-based.
Read past the marketing and there is a real structural claim in there. Audits are things you do to an asset you already own, on your own schedule, to reach completeness. Diligence is something you do to an asset you do not own, on someone else’s schedule, to reach a decision. The pen test is not skipped because it is unimportant. It is deferred because it answers a question that only becomes actionable after the money moves.
The practical consequence: every hour spent making the list more complete is an hour not spent making one item on it decision-grade. Those are not both good uses of a fixed budget, and the audit instinct will spend the entire budget on the first one without ever noticing it made a trade.
A profession that wrote this down
Software has no standards body for technical diligence. Accounting does have one for something structurally similar, and it is worth borrowing the vocabulary even though the standard has no authority over anything you will ever do.
In an agreed-upon procedures engagement, an accountant performs a specific list of procedures and reports what they found — without expressing an opinion on the thing as a whole. The governing standard is explicit that this is not an audit:
“the practitioner does not perform an examination or a review … and does not provide an opinion or negative assurance.” (PCAOB, AT Section 201, para. .03)
And it puts the responsibility for choosing the procedures somewhere that will feel strange the first time you read it:
“Specified parties are responsible for the sufficiency (nature, timing, and extent) of the agreed-upon procedures because they best understand their own needs.” (para. .11)
The illustrative report goes further and says it out loud to the reader’s face: the practitioner makes “no representation regarding the sufficiency of the procedures described below either for the purpose for which this report has been requested or for any other purpose” (para. .32).
Sit with what that posture would mean on your one page. You are not claiming the four axes are the right four. You are claiming they are the four you scored, that here is the threshold you applied, and that the reader — who understands their own investment thesis far better than you do — carries the judgement about whether four was enough. That is a stronger position than implied completeness, because implied completeness can be destroyed by one question you did not ask.
The exchange rate
If completeness is not the virtue, something has to replace it, and the replacement is conversion: every finding that survives has been turned into a quantity a deal team can act on.
A published worked example, from a vendor selling data-room software rather than diligence itself, shows the shape. Its illustrative report prices individual findings — three engineer-months to replace an open-source component, eleven engineer-months for database scaling — and totals them into twenty engineer-months and a stated figure of incremental annual hosting cost. Another firm, this one selling the reviews, lists among its deliverables a remediation roadmap with cost and timeline estimates.
Neither of those is a benchmark and you should not treat them as one — they are illustrative numbers from firms advertising a service, with no independent survey behind them. What they establish is the form: findings arrive with a quantity attached, or they do not arrive.
A finding with no cost and no timeline is an observation. Attach both, or delete the row.
One divergence from the sources, deliberately. They price in dollars; your rubric prices in weeks. A dollar figure smuggles in a rate card, a location, a seniority mix and an overhead assumption, none of which are yours to set, and it converts an engineering judgement into something the reader will treat as costed. Weeks stay inside what you actually know and stay arguable, which is the point — you want the finance people multiplying your weeks by their own rates, not silently inheriting yours.
Check your recall
Answer from memory — no scrolling back.
Hands on
Convert an audit into a diligence
Done when: RUBRIC.md has a Findings table with at least three rows, every row carries a cost in weeks and a confidence, and at least one true observation has been deleted rather than kept.
- Pick a product you know well from the inside — one of your own is fine, and better than fine, because you can check your own estimates against reality later.
- Write an audit-style list first, on purpose: six to ten true things that are wrong with its interface. Do not filter. This is the document your instinct wants to produce, and seeing it written out is what makes the next step feel like a loss.
- Now convert. For each item, try to attach a cost in weeks and an assumed team size. Some will convert immediately. Some will resist, and the resistance is information: an item you cannot cost is usually either too vague to act on or too small to mention.
- Delete every row that would not convert. Aim to end with three or four. If deleting a true finding feels wrong, note in one line why you kept wanting to keep it — that instinct is the audit habit, and naming it is how you will catch it next time under time pressure.
- Fill the surviving rows into the Findings table in
learning/ux-diligence/RUBRIC.md, including the Confidence column. Confidence is not decoration: a high-cost finding you hold at low confidence is the one a reader most needs flagged. - Bring the deleted list and the surviving table into the chat together. The interesting conversation is about what you cut, not what you kept.
What this does not cover
Everything above assumes you can get the evidence to convert a finding into a number. Often you cannot, and the reasons are structural rather than personal: a clock you do not control, access that is negotiated rather than given, and a management team with a direct interest in what you conclude. The lesson on the three constraints is about what those do to the instrument — which questions they quietly kill, and why “not assessed” has to be a real mark on the page rather than an embarrassment you round into amber.
The four axes themselves — UX maturity, front-end debt, agentic readiness and graftability — come after that, once the shape of the instrument is settled.
Read this next — primary source
AT Section 201: Agreed-Upon Procedures EngagementsPublic Company Accounting Oversight Board — free; an accounting attestation standard, not a technical diligence standard
This lesson takes three paragraphs out of it. The reason to read the whole standard is to watch a profession that had this exact problem a century before software did, and then wrote the answer down in enforceable language: who chooses the questions, who carries the risk that the questions were wrong, and exactly what words go in the report so that nobody mistakes findings for an opinion. Your rubric has no standards body behind it and never will. Reading one that does is the fastest way to see which parts of your own position you have not yet made explicit.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.