72 hours of technical diligence: find the three problems that change the deal

You get 72 hours of technical due diligence and your goal is not to find every problem. Your goal is to find the three problems that change the deal.

I’ve sat through a lot of diligence sessions where the technical lead came back with a 40-page report and the operating partner couldn’t tell me what they were going to do about any of it. That’s not diligence. That’s a survey. The report gets filed, the deal closes on the same terms it would have closed on anyway, and the three things that actually mattered surface eight months into the hold, at full price.

The constraint is the useful part. When you only have 72 hours, you can’t catalog. You have to hunt. And after enough of these windows, I’ve learned the three things worth hunting for.

The single point of operational failure

One thing that, if it broke, would stop the business cold for more than a week. It’s almost never the system anyone points you to. It’s usually a coordination layer or an integration nobody documented, the unglamorous piece that everything else quietly syncs through. The team doesn’t flag it because it’s been working for years, and that’s exactly the problem. Nothing that has worked unattended for years has a recovery plan.

The thing the team is hiding

Not maliciously. They’re embarrassed by it. Often it’s the deployment process, or a vendor relationship that’s gone sideways, or the script one departed engineer wrote that everyone is afraid to touch. You find it by watching what people route around in conversation. Diligence questions get fluent answers; the hidden thing gets a topic change.

The embarrassment is a useful signal, because teams are embarrassed by what they’ve lived too close to for too long. The same instinct shows up on the sell side, which is why I tell companies preparing for a process to clean the closet themselves before a buyer’s team does it for them.

The pride that doesn’t pay

One thing the team is proudest of that the business doesn’t actually pay for. Beautiful internal tooling that doesn’t move revenue. Architecture work that won the engineering team’s hearts and the customer’s indifference. This one matters for the model, not the risk register: it tells you where engineering capacity has been going, and whether the roadmap the deal is priced on will get that capacity back.

The 36-hour test

If I can name those three things by hour 36, I’m in good shape. The back half of the window is for pressure-testing them: sizing the exposure, checking whether the team knows about each one, and turning the findings into something an operating partner can act on Monday morning. Not “the platform carries technical debt.” More like “one engineer can deploy to production, here’s the 90-day plan to fix that, and here’s what it costs.”

The 40-page version of the report treats every finding as equal. They aren’t. Most findings are duct tape a buyer should expect at this stage, the mid-market kind we see in nearly every engagement. The job is separating the duct tape from the three things that reprice the deal or rewrite the first-year plan.

I do this work for PE operating partners and portfolio CEOs, on both sides of the table. The sell-side version is the same hunt run a year earlier, when everything found is still fixable at normal cost. If you’re entering a 72-hour window soon, on either side, it’s worth knowing your three before someone else names them for you.