Run the buyer's checks on yourself before the review

How to do it

A buyer who finds a working secret or an unowned module lowers the price or walks away. A seller who found it first can fix it in a week. Ask someone outside the team to run the checks, so the authors do not mark their own code. Never sign a review of code you have changed explains why. Rate findings with Rate every finding on a fixed severity scale. Close the deal-breakers and the fix-before-closing items. Put a written plan with dates next to the rest.

Examples

Python example

def ready_to_sell(findings: list[dict]) -> list[str]:
    blockers = [f["id"] for f in findings if f["severity"] == "deal-breaker" and f["status"] != "fixed"]
    unplanned = [f["id"] for f in findings if f["status"] != "fixed" and not (f.get("owner") and f.get("due"))]
    return blockers + unplanned

JavaScript example

function readyToSell(findings) {
  const blockers = findings.filter(f => f.severity === 'deal-breaker' && f.status !== 'fixed')
  const unplanned = findings.filter(f => f.status !== 'fixed' && !(f.owner && f.due))
  return [...blockers, ...unplanned].map(f => f.id)
}

How to check

A self-review report exists, dated within 90 days of opening the data room, covering every rule ID in this playbook. It has 0 open deal-breakers, and each other open finding has an owner and a date.

Related rules

• TDD-1 Never sign a review of code you have changed in Technical due diligence
• TDD-16 Rate every finding on a fixed severity scale in Technical due diligence