The Slack message that re-prices the deal
It usually arrives on a Thursday afternoon, three weeks into diligence. A buyer's third-party auditor pings your engineering Slack: "Quick question — can you point me to the runbook for the billing service? And is anyone besides Marcus familiar with the reconciliation logic?" There is no runbook. The answer is no. And in that moment, two things happen that you will feel in the wire transfer: the auditor flags a key-person dependency, and they stop trusting your data room.
If you are the CTO of a B2B SaaS or tech-enabled services company heading toward a sale, this is the part of the process nobody warned you about. The financial team has been prepping the Quality of Earnings report for months. Your repos have been prepped for exactly zero days. And the gap between those two states is where a 20% valuation haircut lives.
Here is what changed. Technical diligence used to be a conversation — a couple of senior engineers reviewing your architecture diagram, asking whether you ran on AWS or Azure, confirming a backup existed. It is now a forensic audit. Buyers run automated scanners across every line you have shipped, pull your dependency tree apart, and quantify what it will cost them to live in your codebase after close. The shift tracks the money: McKinsey's work on value creation in software M&A makes the point bluntly — value in these deals is created or destroyed in the integration, and the codebase is the integration. They are not pricing your features. They are pricing the friction of inheriting them.
Why "remediation cost" is the only number that matters
In a Quality of Earnings report, debt is a line item everyone understands. In a Quality of Technology report, your technical debt gets the same treatment — it becomes a dollar figure called remediation cost, and it comes straight off the purchase price.
The math is mechanical and unsentimental. Say the buyer's auditor concludes that decoupling your monolithic billing module to hit their growth plan takes two engineers eight months. They will price that — fully loaded, plus opportunity cost on the stalled roadmap — and subtract it from your enterprise value. You do not get to argue it away in a meeting. You either fixed it before they looked, or you disclosed it with a costed plan attached, or you eat it. KPMG's read on the evolving technology diligence landscape is that scope keeps expanding into exactly these questions — scalability economics, security posture, IP provenance — because that is where the post-close surprises keep coming from.
What the scan actually finds — and the four files you control
The auditor's job is to convert "the founders say it scales" into evidence. Your job, starting six months out, is to make sure the evidence agrees with the founders. Four areas decide that, and a CTO can move all four without a budget approval.
1. The dependency tree is the first thing they unzip
Before anyone reads your application logic, an automated scanner like Black Duck or Snyk walks every package you import. It is hunting two things: copyleft licenses (a GPL component buried in a vendored utility can, in the worst reading, obligate you to open-source the proprietary code sitting next to it) and unpatched CVEs in libraries you stopped updating in 2023. The legal risk is the one that kills deals, because you cannot explain it — a license obligation is binary. Run the scan yourself this week. Generate a software bill of materials. The version of this finding that hurts is the one the buyer surfaces; the version that is harmless is the one already remediated in your changelog with a date on it.
2. Key-person dependency: count the people, not the lines
Buyers will quietly map your commit history. If one engineer authored 70% of the commits to the system that actually makes money, your key-person dependency is one — and a key-person dependency of one is a re-trade waiting to happen, because that engineer is also the person most likely to leave once the earnout vests. The fix is not a retention bonus. It is making the knowledge transferable, which means architectural decision records and "why we built it this way" docs, not just API references. I walked through the mechanics of this in the knowledge extraction playbook. What the buyer is paying for is a system that survives a resignation. If the system only survives because a specific person logs in every morning, you are selling a flight risk, not an asset.
3. Unit economics of compute
In the cheap-money years, a bloated cloud bill was somebody else's problem. Now it is an EBITDA leak, and the auditor will model it directly. The question they answer is not "what do you spend" — it is "can you double users without doubling spend." Pull your cost-per-active-user trend for the last eight quarters. If the line is flat or improving as you scale, that is a story of operating leverage. If it climbs with every cohort, your architecture is not scalable, it is just expensive, and the buyer will discount the growth case accordingly.
4. Security posture they can verify, not posture you assert
A self-attestation is worth nothing in this room. If you do not have a SOC 2 Type II, you are already explaining a gap. But the sharper signal is your last penetration test: if it is 18 months old, or if critical findings are still sitting open, you have told the buyer how you operate under pressure. They will ask for the report and the remediation log. Walk through the exact items they will check in the security posture assessment before they do, because "open critical, untouched for a year" reads as a control problem, and control problems re-price the whole deal, not just the security line.
The six-month sprint that turns surprises into line items
By the time the data room request list lands, the narrative is already written — you are just confirming it. So write it yourself first. If you are roughly six months from going to market, point your technical leadership at this sequence:
- Run the static scan and clear the floor. SonarQube or equivalent across every repo. Drive critical bugs and security hotspots to zero. The remaining code smells become a documented backlog with effort estimates — not an undiscovered liability.
- Draw current state and target state. Two architecture diagrams. Be honest about which parts are monolithic and which are coupled. Show the decoupling plan with sequencing. Honesty here is a feature: it proves you know your own system.
- Build the license and sub-processor ledger. Every library, tool, and vendor that touches customer data, mapped to its license and its contract. This is the document that defuses the dependency scan before it goes off.
- Actually run a failover. Not a tabletop exercise — a real recovery drill, timed. If recovery takes four hours, write down four hours and attach the plan to reach fifteen minutes. A measured number beats an optimistic guess every time.
- Document your AI and data lineage. If any feature uses ML, write down where the training data came from and what you can and cannot represent about it. Data provenance is now a standard diligence question, and "we're not sure" is the wrong answer in a deposition.
The goal is not a flawless codebase — no buyer expects one. The goal is predictability. A technical debt you disclose with a price tag becomes a budget item the buyer can plan around. The same debt, discovered by their auditor on a Thursday, becomes evidence that you do not have your hands on the wheel — and that is what actually moves the multiple. For the failure modes that end deals outright rather than just trim them, read the red flags that kill technology deals.
