The full picture of technical due diligence: Seven evaluation axes
The phrase “technical due diligence” (technical DD) means different things to different people. For some, it is “reading the code.” For others, it is “talking to the engineers.” That ambiguity is exactly what produces the worst outcome of a technical DD: a process that felt thorough but actually surfaced nothing.
This article organizes the definition, scope, and structural anatomy of technical DD. Concrete techniques and question banks for each axis are covered in dedicated companion articles. Here we focus on a conceptual map: what kind of activity technical DD really is.
What is technical DD? Contrasting it with financial DD
Financial DD asks “how much is the company earning, and how much can it earn?” Technical DD asks “can the technology base that supports the business withstand the growth and value creation that lies ahead?”
Put another way, financial DD is the evaluation of outcomes, while technical DD is the evaluation of the machinery that produces those outcomes. A business plan can claim “10x users in three years,” but financial DD cannot tell you whether the architecture or the organization can actually carry that load.
That is why technical DD has to stand as an independent evaluation process.
Three common misconceptions about the scope of technical DD
The fastest way to understand the scope of technical DD is to clear up the misconceptions about it.
Misconception 1: It is “reading the code.”
Code is just one slice of technical DD. In practice, signals that sit outside the code — deployment frequency, attrition, incident response practices — often reveal more about the engineering organization than the source itself. Even if you judge a codebase to be “high quality,” its value as a technical asset changes dramatically if every engineer who wrote it is about to leave.
Misconception 2: It is “specialist work that only engineers can do.”
A large portion of technical DD can be carried out by non-engineers. Organizational, process, and technical-strategy evaluation can be handled with structured interviews, and quantitative metrics (deployment frequency, attrition) can be checked as numbers. Deep dives into code and architecture do require technical specialists, but those deep dives are not the entirety of technical DD.
Misconception 3: It is “the work of finding risks.”
Technical DD is not just risk discovery; it is also value evaluation. Proprietary data assets, scarce technical talent, or an architecture that is genuinely hard for competitors to replicate are all grounds for valuation. A complete technical DD asks not only “what is broken?” but also “what is durable advantage?”
The seven axes: What you actually evaluate
There are several ways to slice the contents of technical DD, but the seven axes below offer practical coverage for most situations.
| Axis | The question | A common confusion |
|---|---|---|
| 1. Architecture | Can the structure withstand future growth? | Confused with “does it work today?“ |
| 2. Code quality | What kind and what scale of technical debt exists? | Slips into aesthetic judgments about “clean code” |
| 3. Infrastructure | What is the availability, cost, and lock-in risk? | ”We use cloud, so we’re safe” is a false comfort |
| 4. Security | Are auth, data protection, and vulnerability management adequate? | Judged purely from compliance paperwork |
| 5. Development process | Does the organization sustain a workable development velocity? | Individual ability and organizational process get conflated |
| 6. Engineering organization | Key-person risk, skill distribution, hiring power? | Code quality is taken as a proxy for the whole org |
| 7. Competitive advantage | Is the technical differentiation hard to copy? | Reduced to “is the tech stack new?” |
How the seven axes interact: They are coupled, not independent
The seven axes are not independent line items. They are coupled. For example:
- Low code quality -> no tests -> deploys are scary -> deployment frequency drops (impacts the process axis)
- High key-person dependence -> high attrition risk -> code quality becomes hard to sustain (impacts the code-quality axis)
- Architectural problems -> cost explodes at scale -> infrastructure cost becomes unpredictable (impacts the infra axis)
When you evaluate, the important thing is not just to score each axis individually but to read how a problem on one axis cascades into others. Critical issues are almost always chains across multiple axes.
Depth of evaluation: Deciding what to look at, and how deeply
Time and resources for technical DD are finite. If you try to evaluate every axis at the same depth, every axis becomes shallow. The discipline that matters is prioritization: deciding what to look at and how deeply.
Two factors mostly determine that depth.
Investment stage and deal size
At the seed stage, axis 6 (engineering organization) and axis 7 (competitive advantage) usually deserve the most weight. The code is going to be rewritten anyway; the people and the concept are much harder to change. From Series A onward, all seven axes should be evaluated in a balanced way, and for M&A or large rounds it is worth bringing in external specialists to dig deeper.
The technology dependence of the business
A startup that claims “AI/ML is the core of our advantage” demands much greater depth on axis 7 (competitive advantage). For “we run a standard SaaS CRUD app,” it is more efficient to concentrate on axis 6 (engineering organization) and axis 5 (development process).
Detail per axis: See the dedicated articles
Concrete checks, recommended questions, and judgment criteria for each of the seven axes are covered in standalone articles.
Code quality and technical debt (axis 2)
The phrase “technical debt” is overloaded; it means different things to different speakers. We re-organize it as a framework that can actually inform investment decisions in What “technical debt” really is, and the patterns that bite startups. It covers the four-quadrant classification and how to distinguish “good debt” from “bad debt.”
Checklist across all seven axes (axes 1–7)
A line-item checklist of what to confirm during DD, organized by axis, is in The complete technical due diligence checklist for investors. It covers architecture, code quality, security, development process, engineering talent, IP, and product metrics.
Evaluation by non-engineers (axes 5 and 6)
How to evaluate the engineering organization without reading the code is the topic of How to read an engineering organization before you acquire it. It walks through pre-interview quantitative checks, a four-axis framing for the discussion itself, and how to feed the output into post-deal integration design.
How to translate technical DD into an investment or acquisition decision
The final output of technical DD is not a verdict like “this company’s tech is good or bad.” The point is to hand three things to the investment or acquisition decision:
- Critical risk identification: risks that move the deal-or-no-deal needle (e.g., legal exposure, irrecoverable technical debt)
- Inputs for term negotiation: findings that should be reflected in valuation, closing conditions, or post-investment milestones
- The basis for PMI / value-up planning: a prioritized list of where to intervene first after the deal closes
The role of technical DD is not “find a problem and kill the deal.” It is “size the risk and its solvability, and feed that into both deal terms and the post-deal plan.”
No startup has a flawless technical foundation. What matters is how accurately the management team understands its own technical risk, what plan they have to address it, and whether the investor can correctly fold that into the investment decision.
Tied Inc. provides technical due diligence support for VCs and corporate M&A teams. See our services for investors for details.