You are about to put money into a company whose main asset you cannot see. The financials you can audit, the contracts you can read, the team you can meet. But the software — the thing that supposedly makes the company worth what they are asking — is invisible to everyone in the room who has not read the code. Technical due diligence is how you make that asset visible before you commit, and skipping it is how sophisticated investors end up owning a liability they mistook for a foundation.
What technical due diligence actually answers
Strip away the jargon and technical due diligence answers one question in several parts: is this technology a foundation you can build on, or a liability you will spend years and money fixing? Everything else is detail underneath that. Can the system scale to the growth the business plan assumes, or will it fall over at three times the current load? What is the real state of the code, the team, the security, and the accumulated debt — not the state described in the pitch, but the state on disk?
The reason this matters is that software risk does not show up on a balance sheet until it is a crisis. A company can look healthy and profitable while sitting on a codebase that only one person understands, a security posture that would not survive a serious look, and a level of technical debt that will consume the next two years of engineering just to stand still. None of that is visible in the numbers you were shown. Due diligence exists to find it before you own it.
There is a second, subtler thing it answers, and it matters most when the technology turns out to be sound: how much of the company's value actually lives in the software at all. Sometimes the real asset is the customer base, the brand, or a distribution position, and the software is merely adequate plumbing that could be replaced. Sometimes the software is the whole moat. Knowing which of these is true changes what you are buying and what you should pay, because a fragile codebase under a business whose value is elsewhere is a manageable cost, while the same fragility under a business whose value is the software is a threat to the entire thesis.
What to look at
A thorough review covers a handful of areas, and each one answers a different worry. Architecture comes first: is the system built in a way that can grow and change, or is it a tangle where every new feature makes the next one harder? You are not looking for elegance for its own sake — you are looking for whether the structure can carry the roadmap the valuation depends on.
Then key-person risk, which is often the single largest hidden danger. If the whole system lives in one engineer's head, the company is one resignation away from a crisis, and no amount of clean code compensates for that. You want to know how many people genuinely understand the core, how much is written down, and what happens the day the original author leaves. Security is next — not a box-ticking checklist, but an honest read of how exposed the company is and how it would fare under real scrutiny. Then licences and intellectual property: does the company actually own what it thinks it owns, or is the product quietly built on open-source components whose licences forbid exactly the commercial use being sold? That question has ended deals.
Finally, the two things that reveal character rather than state: the credibility of the roadmap — whether the plan for the future is grounded in what the system can actually do — and the delivery track record, which tells you whether this team can reliably ship. A convincing roadmap on top of a team that has never delivered on time is a story, not a plan.
The red flags that matter
Some findings are ordinary — every real codebase has debt and rough edges, and their absence would be more suspicious than their presence. Others are genuine warning signs. A system only one person understands is near the top of the list. So is a team that cannot clearly explain how their own system works, or that becomes defensive when asked straightforward questions — competent teams are usually relieved to talk to someone who understands the problem.
Watch for a codebase where routine changes are slow and frightening, because that tells you the cost of every future feature is higher than the plan assumes. Watch for security treated as something to address later, for a product built on licences nobody has actually checked, and for a roadmap that promises capabilities the current architecture plainly cannot support without a rebuild nobody has budgeted. And watch for the softest signal of all: a team that talks fluently about what they will build and vaguely about what they have shipped. The past tense is where the truth lives.
Why the demo never tells you enough
The demo is designed to impress you, and it usually does. That is precisely why it is nearly worthless as evidence. A demo shows the software on its best day, on the happy path, with data chosen to flatter it, run by the people who know exactly which buttons not to press. It tells you the product can look good in a controlled room. It tells you nothing about what happens under real load, with real messy data, when an ordinary user does something unexpected.
More importantly, a demo shows you the surface and hides the structure entirely. The most dangerous problems in software are invisible from the front: the architecture that cannot scale, the single point of human failure, the security hole, the mountain of debt behind a clean screen. You can watch a flawless demo of a system that is one bad week from collapse. Judging a software asset by its demo is like buying a building on the strength of the lobby — reassuring, and completely beside the point. The questions that decide whether you have bought well are never asked on stage; they are asked in the code, in the deployment history, and in a candid hour with the people who maintain it.
Use an independent expert
There is a structural reason to bring in someone from outside for this. The team being assessed cannot assess itself honestly — not because they are dishonest, but because they are too close, too invested, and often genuinely blind to the risks they have lived with for years. And you, the investor or the board, usually lack the technical depth to know whether the answers you are getting are real or reassuring. An independent expert sits in the gap: technical enough to read the code and the architecture, and detached enough to have no stake in the deal closing.
Independence is the whole value. An assessor who benefits from the deal going ahead is not doing due diligence; they are doing sales with a technical vocabulary. What you want is someone whose only job is to tell you the truth about the technology, whose reputation depends on being right rather than on being agreeable, and who will say the uncomfortable thing while there is still time to act on it. The cost of that assessment is trivial against the cost of discovering the same facts after the money has moved.
There is a practical reason the outsider gets better answers, too: they can ask the questions you cannot. An investor probing too hard risks souring a relationship they may depend on once the deal closes, while the founders will tell a neutral technical peer things they would never volunteer to the person holding the cheque. A good assessor uses that opening carefully — not to catch anyone out, but because the honest picture only emerges when the engineers being questioned believe the person asking understands the work and is not there to score points. That rapport is part of the method, and it is one more thing you cannot get from reading the numbers yourself.
Frame it as a map, not a verdict
Here is the mindset that makes technical due diligence useful rather than adversarial. Its output should not be a thumbs up or thumbs down. It should be a map of risk — a clear picture of where the strengths are, where the dangers lie, how severe each one is, and what it would cost to address. A deal is rarely killed by a single finding; it is shaped by understanding the whole terrain before you walk into it.
This framing changes how everyone behaves. If due diligence is a verdict, the target company defends and hides. If it is a map, the same information becomes something both sides can use — to price the deal correctly, to plan the first year, to know what to fix first. A good assessment does not just tell you whether to proceed. It tells you what you are actually buying, what it will take to make it worth the price, and where to spend your attention the day after the deal closes. That is worth far more than a verdict, and it is what separates diligence that protects you from diligence that merely comforts you.
The map is also the thing you keep. A verdict is spent the moment the deal closes; a map keeps working. It becomes the first draft of your hundred-day plan, the brief for the engineering leader you hire, the checklist you hold the team against in the first quarter. The risks it named do not vanish because you signed — they become the work, and a company that walks into ownership already knowing where the weak walls are can shore them up deliberately instead of discovering them under load. Framed this way, the assessment stops being a gate you pass through and becomes an asset you carry into the relationship, which is a far better return on the same modest cost.