The clock that starts the day you sign the LOI
Here is how the worst version of this goes. You sign the letter of intent at a number you're proud of. Three weeks into exclusivity, the buyer's technical diligence team has run Black Duck and SonarQube across your repository — automated scanners that map every open-source dependency, every unpatched CVE, every license in your stack — and they ask for a call. On that call, the partner is polite. The number, however, has moved. McKinsey's research on reclaiming tech equity frames technical debt as a drag of 20-40% of a company's entire technology estate value, and in a deal context that drag doesn't stay abstract. It gets priced. A re-trade in the low double digits on a real purchase price is not a rounding error — it's the difference between two materially different lives.
The founder instinct, once you understand a buyer is going to crawl the codebase, is to authorize a Grand Rewrite. Burn the legacy modules down, rebuild them clean, hand over something pristine. Don't. A rewrite stalls the feature velocity that justifies your multiple in the first place, ships a fresh crop of bugs into code the buyer hasn't seen yet, and almost never finishes on the timeline you promised the board. You'd be trading a known, containable problem for an unknown, uncontainable one — six months before the most scrutinized period of your company's life.
The mindset that actually works: the buyer is not grading your code for elegance. They are pricing the surprises in it. Your job between LOI and close is not to make the codebase beautiful. It is to make it boring — predictable, documented, free of the three findings that turn a polite diligence call into a price negotiation.
Three findings that move the price — ranked by how badly
Run the scan on yourself before they run it on you. Same tools, same rigor, four weeks earlier. The point isn't to fix everything; it's to know exactly what they'll find so nothing on their report is news to you. Here's what to look for, ordered by how much damage each one does in a negotiation.
Copyleft contamination — the one that doesn't just discount the deal, it can void the asset. Most founders worry about CVEs. The finding that actually keeps deal lawyers up at night is a GPL or AGPL-licensed component sitting inside your proprietary, revenue-generating code. Under a strict reading, that license can obligate you to open-source the work it touches — meaning the thing the buyer is paying for might not be exclusively yours to sell. The Open Source Security and Risk Analysis report documents how routinely high-risk and license-conflicted components show up in commercial codebases. This is the one to hunt first, because the remediation has a lead time: you either rip the component out, wall it off behind a service boundary so the copyleft obligation doesn't propagate, or re-license it — and none of those happen in a weekend.
Unpatched CVEs in your dependencies — the credibility tax. Active, publicly known vulnerabilities in your third-party libraries are a fast no in security review, and they cost you more than the patch. A diligence team that finds a year-old critical CVE you never addressed quietly reclassifies everything else you've told them. If you didn't patch a known hole, what else didn't you do? Stand up automated dependency updates and a written patch cadence now, so by the time they scan, the answer to "how do you handle this" is a process, not a shrug. Stripe's Developer Coefficient work quantifies how much engineering time leaks into exactly this kind of maintenance — which is also why "we'll get to it" is never the honest answer to a buyer.
A single load-bearing database — the CapEx the buyer prices in. If your whole platform hangs off one monolithic database approaching the ceiling of vertical scaling, the buyer doesn't see a technical detail. They see a multi-quarter, seven-figure re-platforming bill landing in year one of their hold, and they'll subtract it from what they pay you. You do not need to be on microservices by close. You need to show a credible path to horizontal scale — a sharding strategy, a read-replica plan, a documented decision on where the seams are — so the buyer prices a manageable roadmap instead of an emergency.
Six months, three moves, and a build that runs in under an hour
You don't need to refactor the company. You need a finite, sequenced containment sprint that lowers risk while your roadmap keeps moving — because the moment feature velocity drops, the buyer starts asking why.
Months 1-2 — scan, fix the unforgivable, document the rest. Patch the critical security flaws immediately; those are the only things you truly cannot leave for the data room. For the architectural debt you can't unwind in sixty days, write it down. A buyer will forgive a known weakness that comes with an honest mitigation plan and a cost estimate. What they punish — with the steepest discount — is the risk they discover themselves. Disclosure is leverage; surprise is a discount you handed them. When the board pushes back on spending engineering time on cleanup instead of features, model the dollar cost of each unaddressed item against the exit value it threatens — the math usually ends the debate.
Months 3-4 — strangle, don't rewrite. For the legacy modules that scare you, wrap them behind a clean API and build everything new against the modern interface. The old code keeps running, untouched and contained; new development happens in a current stack. This pattern does double duty — it lowers your actual risk, and it gives the diligence team something concrete to point to when their report asks "what is the modernization strategy?" "We have a strangler pattern in production" is a far better answer than "we plan to."
Months 5-6 — prove it with a clean build. Make your build and deploy pipeline fully automated, then test it the way the buyer will: can a stranger clone the repo and produce a working build in under an hour? If it takes a key engineer half a day and tribal knowledge, the diligence team concludes your velocity is inflated and your bus factor is one — and they price that risk too. A one-command clean build is the cheapest, most convincing proof of operational maturity you can hand them.
Start the self-scan the week you decide an exit is on the table, not the week you sign the LOI. The four weeks you buy yourself between knowing what's in the codebase and the buyer knowing is the entire game.
