The 5-Day Technical Due Diligence Sprint That Finds the CAPEX Bomb Before You Sign

The clock starts when you get repo access, not when the report lands

Picture the Tuesday a deal team gets read-only access to a target's GitHub org for the first time. Twelve weeks later, a Big 4 team hands back a 100-page red-flag binder—and by then the exclusivity window has closed, the seller has read your hesitation, and the number on the LOI hasn't moved. You didn't lose the deal on price. You lost it on speed.

That gap matters because the standard playbook measures the wrong thing. It inventories what the target has—repos, headcount, a tidy architecture slide—and almost never measures what those assets actually cost to keep running. McKinsey's research on technical debt is blunt about where that goes: a meaningful slice of the engineering estate gets consumed servicing debt rather than building anything new, and the cycle compounds quietly until a replatform forces the bill due (McKinsey: Breaking Technical Debt's Vicious Cycle). For a middle-market SaaS target, that interest payment is invisible on the P&L you're underwriting—it shows up as "R&D" with no line item saying "we spend 30% of this keeping a 2019-era framework alive."

Here's the failure pattern I see most. Say a 60-person SaaS company looks pristine: healthy gross margin, steady net revenue retention, a clean org chart. A high-level architecture review would bless it. But the core platform sits on a framework approaching end-of-life, and replatforming it lands somewhere around a year of senior engineering capacity—a CAPEX event that arrives in month nine of your hold, not at close. A surface review never finds that, because the debt doesn't live in the architecture diagram. It lives in the commit history, the dependency manifest, and the cloud bill. The point of a five-day sprint isn't to rush. It's to look in the three places the slide deck never shows you, fast enough to still act on what you find.

What you actually do, hour by hour, for five days

This is not a compressed twelve-week audit. It's a different instrument, built to convert engineering signal into deal terms while you still have leverage. Each day produces one decision input, not a chapter.

Day 1 — Let the code testify before any engineer does

Run a software composition analysis against every repo before you sit in a single management interview. Memories are curated; dependency manifests are not. Synopsys's open-source risk analysis found high-risk vulnerabilities in roughly three-quarters of the commercial codebases it scanned (Synopsys OSSRA Report), so assume you'll find them and triage instead of gasping. Three things end the day on your list: high-severity CVEs that put SOC 2 or a key customer renewal at risk; copyleft (GPL-family) licenses tangled into the proprietary core, which can put your IP claim itself in question; and component age, because a stack where half the libraries are four-plus years stale is telling you maintenance cost is about to climb whether or not you ship anything. Gartner's guidance on software supply chain security maps neatly onto this—provenance and SBOM gaps are now a diligence line, not an afterthought (Gartner: Software Supply Chain Security).

Day 2 — Read the cloud bill as an architecture diagram

Ignore the microservices slide; pull twelve months of cloud invoices and the autoscaling logs next to monthly active users. Plot cost against usage. If onboarding another thousand users drags infrastructure spend up roughly in lockstep, you're looking at a monolith wearing a modern logo, and the unit economics get worse as the thesis works. The shape of that curve is your scalability answer—and it's already audited, because the cloud provider billed for it.

Day 3 — Find out how many people can quit before the roadmap stalls

In founder-led targets, a startling share of the load-bearing code traces to two or three contributors. Mine the commit history by file ownership: if the modules that generate revenue have a single author, your key-person dependency is one human, and that fact belongs in the retention package, not a footnote. This is where the technical debt picture stops being abstract: debt plus a bus factor of one is a different risk than debt with a deep bench.

Day 4 — Measure whether they can actually ship

Ask for cycle time—the elapsed hours from a code commit to that code running in production—and look at the deploy and rollback logs to verify the answer. Elite teams measure this in hours; a fragile manual pipeline measures it in weeks of stress. If your value-creation plan assumes fast product expansion and their release process is a person clicking through a runbook at 11pm, your first year goes to building plumbing instead of features. Cycle time predicts how much of your thesis is real.

Day 5 — Sort every finding into three financial buckets

Translate the week into the only language the IC reads. Deal killers: unscalable core, IP exposure from a license entanglement, an unpatched breach. Day-one CAPEX: mandatory remediation inside the first 100 days, each with a dollar estimate. VCP OpEx: the hires and tooling the growth plan requires. Nothing leaves the room as "a bug." Everything leaves as a number with a timeline.

Turn the findings into a CAPEX bridge—then into a price

The deliverable that matters isn't a bug list; it's a bridge from the seller's stated EBITDA to the real one, with each engineering finding carrying a dollar figure and a quarter it lands in. If the sprint surfaces, say, a couple million in mandatory remediation to support the growth thesis, that's not commentary—it's purchase-price reduction or holdback, structured against the milestones that retire the risk. Sellers argue with adjectives. They have a much harder time arguing with a dated remediation schedule tied to their own commit logs and cloud invoices.

Consider a hypothetical that mirrors what these sprints tend to expose: a logistics platform with a polished front end but a database schema hard-wired to one customer type. The whole investment thesis was expansion into new verticals—which the data layer physically could not support without a rewrite measured in months and seven figures. An operating partner armed with that finding negotiates against a specific number and structures a milestone earnout for the CTO to deliver the new schema, rather than discovering the constraint two quarters into the hold. Same company, two outcomes—the difference is whether the constraint was priced at the table or paid for later.

By Friday afternoon you should be able to answer three questions without hedging: is the debt terminal (cheaper to rebuild than to fix), can this team execute the VCP or do you need a new VP of Engineering in the first 90 days, and what is the actual EBITDA once you've adjusted R&D for the maintenance the legacy code really demands. Monday move: before your next IC, ask the deal team for read-only repo access on day one of diligence and run the Day 1 scan yourself. If you can't put a number on engineering efficiency inside the first week, you won't be able to manage it for the next five years—and you'll be paying the seller's debt with your own EBITDA.