The goal isn't a code review
A line-by-line style critique is the wrong deliverable — nobody closing a deal in two weeks needs a list of every lint warning. The goal is a decision-ready answer to one question: what would it cost, in time and money, to keep this running and extend it after close?
What actually predicts post-close pain
Four things, roughly in order of how often they turn into real cost: bus-factor (does the system depend on one person who may not stay), operational maturity (can it be deployed, rolled back, and debugged without the original author), architectural debt that blocks the roadmap the buyer actually wants to execute, and security/compliance exposure that becomes the buyer's liability the moment ink is dry.
What to deliberately skip
Style disagreements, framework preferences, and anything that's a matter of taste rather than a matter of risk. A due diligence report that reads like a personal code-review leaves the reader unable to tell what's actually load-bearing.
Turning findings into a number
Every finding should resolve to one of three things: a dollar figure to fix it, a timeline risk to a specific roadmap item, or a walk-away flag. "The auth layer has some issues" isn't decision-ready. "Replacing the auth layer is a 3-week fix, ~$40k at market rate, and blocks nothing on the 90-day roadmap" is.
Timing
Diligence runs on the deal's clock, not the codebase's. A fixed, fast turnaround — days, not weeks — with a clear scope up front is what makes the report usable instead of a document that arrives after the decision already got made some other way.