The code that passes the pitch and fails due diligence

I talked to founders who went through technical diligence and watched the term sheet shrink — not over the product, but over the paperwork, the code's ownership, and everything nobody had read with a buyer's eyes. Why the time to fix it is long before the round.

For months I kept hearing the same scene told from different angles. A founder lands the round's narrative, the investor likes it, a term sheet shows up. Then technical diligence starts, someone from outside opens the repository, and the number on the page starts to shrink.

In May I talked to the founder of a healthtech company who had just been through it. Series A on the table, an eager lead, and a consultant the fund had hired to read two and a half years of product. The report came back at thirteen pages. The part that stung wasn't a bug: it was that nobody on the cap table could say who legally owned the code written by a studio she'd hired in year one and let go later. The contract was boilerplate. So was the IP clause.

Her product worked fine. What failed was everything around it: the contract, the ownership, a history nobody had read with a buyer's eyes.

Two people going over a report, pen on the chart: diligence reads what the pitch left out.

I've written about engineering teams for a while, and this is the gap that catches my eye the most. A pitch is a sales object: it shows the traction, the line going up, the demo that works. Diligence is the opposite of a pitch. It doesn't want the good story, it wants what sits underneath. And what sits underneath is rarely built with the day in mind when someone from outside lifts the lid.

Diligence opens what the pitch keeps shut

Technical diligence is not bug hunting. A serious consultant spends three to five days looking at a set of things the founder almost never measured:

• Intellectual property: who signed what, and whether third-party code actually became yours.
• Knowledge concentration: how many people understand the system, and what happens if the main one leaves.
• Basic security: a secret committed to the repo, a dependency left unpatched, a door left open.
• Ability to ship: how long it takes from a commit to production, and how many hands have to get involved.

None of these show up in a demo. All of them show up in a report. Which is why diligence is usually the first time a founder sees their own product through the eyes of the person about to pay for it.

"We'll clean it up before the round" doesn't survive contact

The most common reaction, when I raise this in conversation, is to defer. "When the round gets close, we'll get organized." It feels like the natural order of things. Except diligence won't wait for you to be ready.

You can't document two years of decisions in three weeks. Rewriting an IP contract with a vendor who already walked away is a slow negotiation, sometimes with someone who no longer picks up. Testing code that never had tests, written by people no longer on the team, is archaeology. Diligence lands in the worst possible window: when you have the least time and the most to lose. Show up improvising and the report becomes the other side's discount argument.

The counter has no shine to it, and it works: a team that operates, from day one, as if the lid could be lifted at any moment. The squads we work with at Revin run that way by default, with a round on the horizon or none at all. Code that passes diligence is the same code that doesn't break in production, and the discipline behind one is the discipline behind the other.

If you suspect your code would not survive an outside read, a Diagnostic Sprint lifts the lid before the investor does. Worth a look.

What usually shows up in the report

I've read more diligence reports than I'd like, and a few patterns keep repeating. A production secret committed in plain text somewhere in the Git history, where it never truly disappears. One person holding the core of the system in their head, with nothing written down. Libraries two or three major versions behind, carrying a known and public vulnerability. A deploy that hinges on a manual step living in someone's memory.

Across the projects that reached me for a second opinion this past year, something like two-thirds had at least one secret exposed in the repository. That number is probably skewed, I'll admit: nobody calls me to talk about the diligence that went well. But even cut in half, it's too high for a problem that costs a day to fix and a whole round to discover late.

A team around one laptop: code that passes an outside read is built by people who expected one.

The report doesn't ask who wrote it

Here's a misunderstanding that trips founders up. A bad diligence result is not a synonym for outsourced engineering. I've seen in-house teams leave a repository in a state that would embarrass any vendor, and I've seen an external squad hand over code the fund's consultant praised in writing. The question that matters is only one: was the code written with discipline, or was it a patch job?

A patch job has a recognizable signature: the freelancer who showed up for three months and vanished, the studio that shipped the MVP and handed back a boilerplate contract, the agency that billed by the hour and left no test behind. Each one solved the week's problem and none thought about the report coming two years later. A managed senior squad does think, because the same discipline that makes a test pass is the one that gets an IP clause signed and keeps a secret out of the repo.

Who actually owns the code, by the way, deserves its own piece, and there is one here.

Back to that founder

The healthtech closed its round, but smaller than it was worth, with part of the money earmarked to fix what diligence had flagged. She left me with a line I keep repeating: "I paid for the same code twice: once to write it, once to prove it was mine."

I'm not writing this to scare anyone raising capital. I'm writing it because diligence is just the moment the bill arrives; the spending happened much earlier, in the choice of who built the thing and how. If you want the outside read to be a stamp instead of a shock, the time to deal with it is now, long before the term sheet.

Want an honest read on the real state of your code before a fund does theirs? Talk to Revin.