When you buy a company or invest in a startup, you hire people to check the numbers. A financial due diligence looks at the revenue, the contracts, the liabilities, the tax position. Nobody signs a serious deal without one.
Then the same buyer signs off on the software — the thing they're often actually paying for — on the strength of a demo and the founder's word that it "scales."
That's the gap. The asset you're acquiring is a codebase, and almost nobody looks inside it before the money moves.
What You're Actually Buying
In a software business, the code is not a detail. It is the product, the moat, and the ongoing cost, all at once. A polished interface tells you nothing about what's underneath it — I've opened codebases that demo flawlessly and fall apart the moment a second customer shows up, real data arrives, or someone reads the code carefully.
A technical due diligence answers the question the financials can't: is the software you're paying for an asset or a liability dressed as one? It's a structured read of the code, the architecture, and the history by someone who has no stake in the deal closing — done before you sign, not after.
Here's what it tends to surface, and why each one costs real money.
Hidden rewrite cost. The most expensive surprise in any software acquisition is discovering, three months after closing, that the thing you bought has to be substantially rebuilt before it can do what you were told it already does. This is not rare. A product that was rushed to a demo, or built by one founder over weekends, or generated largely by AI with nobody steering, can look complete and still need most of its foundation replaced before it's safe to grow. If that's the situation, you want to know it while it's still the seller's problem to explain — not yours to pay for.
Key-person risk. A great deal of software runs on knowledge that lives in one person's head — the founder, or one senior engineer, who knows why a particular thing works and what breaks if you touch it. Deployment steps that exist nowhere but their memory. A critical service nobody else can fully explain. If your deal assumes that person stays, or if it assumes they can leave cleanly, a diligence tells you which assumption is safe. The undocumented system that only works because one person is still answering the phone is a liability you're inheriting, whether or not it appears on any balance sheet.
Security and compliance debt. Secrets committed into the code history. Customer data handled in ways that would not survive a regulator's question. Authentication held together by several half-finished attempts, one missed check away from a breach. These don't show up in a demo and they don't show up in the P&L — but they show up eventually, and by then they're your breach, your fine, your disclosure to make. A diligence finds the obvious exposure before it becomes an inherited emergency.
"Scalable" that isn't. "Built to scale" is the most common claim and the least examined. Sometimes it's true. Often it's a story the team believes because the product hasn't yet been tested by the volume the deal is priced on. There's a specific, readable difference between software that will handle ten times the traffic and software that will fall over at three times — and it's visible in the code long before it's visible in production. If you're paying a multiple that assumes growth, you want to know the architecture can actually carry it.
How It Protects the Deal
A technical due diligence rarely kills a deal. More often it changes the terms — and that's where it earns its cost several times over.
If the diligence finds that the platform needs six figures of rebuilding before it can grow, that's not a reason to walk away. It's a number that belongs in the price, or in an earn-out, or in a warranty from the seller. A finding you have in writing before signing is a negotiating position. The same finding discovered after closing is a loss you absorb alone.
The report gives you three things a demo never will: a clear picture of what's actually there, the top risks ranked by what they'd cost you, and a realistic range for what it takes to fix or grow the system. You go into the negotiation knowing what you're buying instead of hoping. Sometimes the diligence confirms the software is genuinely good — and that's worth paying for too, because now you're committing real money with a calibrated view instead of a hopeful one.
The independence matters as much as the findings. The founder is not a neutral narrator of their own codebase — not because they're dishonest, but because they've lived inside its problems long enough to stop seeing them. You need someone who reads it on its own terms, has no incentive for the deal to close, and tells you plainly what they see.
When It's Worth It — And When It Isn't
I'll be direct about this, because most people writing about due diligence are selling it and therefore tell you every deal needs one.
Not every deal does.
A technical due diligence is worth it when the software is a material part of what you're paying for and the downside of being wrong is large. Concretely:
- The valuation depends on the technology. You're paying a multiple that assumes the product scales, or that a rebuild isn't looming. If that assumption is wrong, the price is wrong.
- The deal is large enough that a rewrite would hurt. If discovering a six-figure remediation cost after closing would meaningfully change whether this was a good decision, the cost of finding out beforehand is trivial by comparison.
- You can't personally judge the code. A non-technical buyer or investor has no way to check this asset the way they'd check a spreadsheet. That's exactly the gap an independent read closes.
- The seller's story leans hard on technical claims — "scalable," "AI-powered," "proprietary platform" — that you have no way to verify yourself.
And it's honestly not worth it when the deal is too small to bother.
If you're acquiring a tiny product for a price where a full rebuild would still be cheap — where you could throw the code away and it wouldn't change the economics — a formal diligence is process for its own sake. If the software is incidental to the deal and the real value is the customer list, the brand, or the team, then diligence the thing that actually matters and don't spend money studying code you might not keep. And if you have the technical judgment to read it yourself, or a trusted engineer who can, you may not need to hire the read at all.
The test I'd apply: would a serious technical problem, discovered after you sign, change whether this was a good decision? If yes, get the diligence — it's cheap insurance against an expensive surprise. If no, skip it and put the money where the risk actually is.
That last part is the whole point. A due diligence isn't a ritual you perform to feel responsible. It's a tool for finding out whether the most expensive assumption in your deal is true, while you can still do something about it.
If you're about to acquire a company, buy a codebase, or invest in a software startup and the technology is a material part of what you're paying for, that's exactly the situation a pre-purchase read is built for. Get in touch and I'll tell you honestly whether your deal needs one — and if it doesn't, I'll say that too.
