The Five Questions Your Technical Due Diligence Should Always Answer

We've reviewed technical diligence reports from firms ranging from boutique advisors to Big Four consultancies. The majority share the same flaw: they describe the technology without evaluating the risk.

You'll get an inventory of programming languages, a list of cloud services, a diagram of the architecture, and maybe a paragraph about technical debt. What you won't get is an answer to the question that actually matters: what does this technology mean for the investment thesis?

A useful technical diligence report doesn't just describe. It evaluates. It quantifies risk. It connects what it finds in the codebase to what it means for your model. And it answers five specific questions.

1. Can this system support the growth the deal model assumes?

Every acquisition model has a growth assumption baked in. Two-year revenue doubles. New market entry. Product line expansion. The question is whether the technology can execute against those assumptions, or whether it will become the bottleneck.

This isn't about whether the system will "scale." Everything scales if you throw enough money at it. The real question is about the cost and speed of change. Can the engineering team ship the features required by the growth plan at the pace the model assumes? Or will they spend the first 18 months paying down technical debt before they can build anything new?

What to look for:

• Deployment frequency and cycle time. Teams that deploy weekly can iterate toward growth targets. Teams that deploy quarterly cannot.
• Architecture modularity. Monolithic systems with tight coupling require more coordination, more risk per change, and more time to adapt. You need to know whether "add a new product line" means six weeks or six months.
• Infrastructure headroom. Not just whether the servers can handle 2x traffic, but whether the data layer, the integration points, and the third-party dependencies can absorb growth without rearchitecture.

A growth plan that depends on technology the company can't change quickly enough isn't a growth plan. It's a wish list with a timeline attached.

2. What is the true cost of the engineering organization?

Headcount and salary data tell you what you're paying. They don't tell you what you're getting. The productive capacity of an engineering organization can vary by 5x between companies of the same size, and the difference is almost entirely a function of technical environment.

An engineer spending 40% of their time navigating a legacy codebase, waiting for builds, or manually testing regressions is dramatically less productive than one working in a modern, well-tooled environment, even if they're equally skilled. This gap is invisible in financial statements but enormous in practice.

What to evaluate:

• Time-to-productive-change. How long does it take from "we decided to build this" to "it's live in production"? Measure it. Don't ask management to estimate it.
• Rework rate. What percentage of engineering time goes to fixing bugs, handling incidents, and working around known issues? This is the tax on productivity that no one puts in the model.
• Automation coverage. Manual testing, manual deployments, and manual infrastructure management are all hidden labor costs. They also introduce human error that creates more rework.

When you understand the true productive capacity of the engineering team, you can model technology investments accurately. Without it, you're guessing. And the guess is almost always optimistic.

3. Where are the single points of failure?

Every system has them. The question is whether they've been identified and managed, or whether they're lurking. Single points of failure come in three forms, and you need to check all three:

Technical single points of failure. The one database that everything depends on. The integration that has no fallback. The service that was built five years ago, never documented, and runs on a server that nobody knows how to replace. These are the things that cause outages that make headlines.

People single points of failure. The engineer who is the only person who understands the billing system. The DBA who has the only access to the production database. The architect who designed the system and left, but whose undocumented decisions are baked into every component. When these people leave (and they will), what happens?

Vendor single points of failure. The critical integration partner with no SLA. The SaaS platform that the entire workflow depends on, with no migration path if they change pricing or shut down. The contractor who built the mobile app and owns the deployment credentials.

A well-run diligence identifies these, quantifies the risk of each, and estimates the cost to remediate. A poor one doesn't look.

4. What will integration actually cost and how long will it take?

If the deal involves integrating the target with an existing portfolio company or platform, this question is the most consequential of the five. And it's the one that diligence reports most consistently get wrong.

The reason is structural: integration complexity is nonlinear. Connecting two systems isn't twice as hard as connecting one. It's an order of magnitude harder, because you're dealing with data model conflicts, authentication mismatches, workflow incompatibilities, and the organizational friction of getting two engineering teams to agree on anything.

What diligence should examine:

• Data model compatibility. How do the two systems represent customers, transactions, products? If the answer is "differently," that's months of mapping, transformation, and deduplication work before anything else can happen.
• API surface and maturity. Does the target expose well-documented APIs, or will integration require building custom connectors into a system that was never designed to be connected?
• Authentication and authorization architecture. Merging user identity across systems is one of the most underestimated integration tasks. If both systems have their own user model, reconciling them is a project in itself.
• Organizational readiness. Does the target's engineering team have experience with integrations? Have they done it before? Do they have the bandwidth to support it while maintaining their existing product?

The output of this analysis should be a realistic integration timeline and cost estimate. Not the optimistic one that makes the deal work on paper, but the one that accounts for what actually happens when two systems meet.

5. Is the technology a moat or a liability?

This is the question that ties everything together. After examining scalability, productivity, risk, and integration complexity, you need a clear-eyed assessment of whether the technology is a competitive advantage worth paying for, or a legacy system that happens to be generating revenue while it slowly decays.

Technology is a moat when:

• It enables capabilities that competitors can't easily replicate
• It has data assets that accumulate value over time
• It can be extended and adapted faster than alternatives can be built
• It attracts and retains strong engineering talent

Technology is a liability when:

• It requires constant maintenance just to keep running
• It constrains what the business can offer or how fast it can move
• It depends on scarce skills or deprecated platforms
• It would be cheaper to replace than to maintain over the hold period

Most companies fall somewhere in between, with elements of both. The value of this question isn't arriving at a binary answer. It's forcing an honest assessment that informs the price, the integration plan, and the value creation roadmap.

The bottom line

Technical due diligence isn't an IT checkbox. It's a core part of the investment decision. The five questions above won't appear in a standard diligence template, but they're the questions that determine whether the technology helps or hinders the deal thesis.

If your current diligence process can't answer them, you're flying blind on one of the most consequential aspects of the acquisition. And in a market where value creation depends on operational execution, that's a risk you can't afford.