Technical Due Diligence: What to Examine Before Trusting a Technology System#

Why Technical Due Diligence Exists#

A technology product can look healthy from the outside while hiding substantial technical problems.

A product may have:

• a polished interface;
• active users;
• a working website;
• a large codebase;
• impressive infrastructure;
• artificial intelligence;
• strong sales;
• or a long list of features.

None of these facts, by themselves, tell you whether the underlying technology is maintainable, secure, scalable, transferable, or economically sensible.

Technical due diligence exists to answer a different question:

What is the technical reality behind the product, and what risks or obligations should a business understand before making an important decision?

That decision might involve:

• acquiring a company;
• investing in a technology business;
• purchasing software;
• entering a strategic partnership;
• taking over an existing project;
• preparing a product for production;
• replacing an incumbent development team;
• or deciding whether a system should be rebuilt.

Technical Due Diligence Is Not a Code Review#

A code review examines source code.

Technical due diligence is broader.

A due-diligence review should connect technical findings to the business decision.

A database design problem matters differently for a small internal application than for a system expected to support millions of transactions.

The Main Questions#

A useful technical due-diligence process should establish:

1. What exists?
2. How does it work?
3. Who controls it?
4. How is it operated?
5. How secure is it within the review scope?
6. What dependencies does it have?
7. What technical debt exists?
8. What happens as the business grows or changes?
9. What technical investment is likely to be required?
10. Which risks could materially affect the business decision?

These questions should be answered with evidence wherever possible.

1. Understand the System Before Judging It#

The first step is not searching for defects.

It is understanding the system.

Useful evidence may include:

• architecture diagrams;
• repositories;
• deployment configuration;
• infrastructure;
• database schemas;
• API documentation;
• product documentation;
• dependency manifests;
• monitoring;
• incident history;
• development workflow;
• release process.

A reviewer should understand the system's intended purpose before interpreting technical choices.

2. Architecture#

Architecture review should examine the major components and their relationships.

Questions may include:

• What are the major services?
• Where does application state live?
• How does data move between components?
• What external systems are required?
• Where are authentication boundaries?
• Which components are critical?
• What happens when a dependency fails?
• Where are the major scaling constraints?

The goal is not to determine whether the architecture is fashionable.

The goal is to determine whether it is appropriate for the product and its requirements.

3. Source Code and Engineering Quality#

A due-diligence review can examine:

• repository organization;
• code structure;
• test coverage where meaningful;
• dependency management;
• error handling;
• configuration;
• secrets handling;
• documentation;
• development practices;
• release history;
• technical debt.

A large amount of code is not evidence of quality.

Likewise, a small codebase is not automatically simple or poor.

The relevant question is whether the implementation can support the product's actual requirements.

4. Infrastructure#

Infrastructure can become a hidden source of operational risk.

Review areas may include:

• cloud architecture;
• deployment;
• environments;
• permissions;
• secrets;
• networking;
• storage;
• backups;
• monitoring;
• logging;
• disaster recovery;
• infrastructure-as-code;
• third-party services.

A product that works on a developer's machine is not necessarily operationally ready.

5. Security#

Security due diligence can examine:

• authentication;
• authorization;
• secrets;
• sensitive data;
• encryption;
• network exposure;
• dependencies;
• access control;
• logging;
• administrative interfaces;
• cloud permissions.

The depth should depend on the system.

A due-diligence review is not automatically a penetration test or formal security audit.

Those may be separate activities.

6. Dependencies and Vendor Exposure#

Technology rarely operates alone.

Important dependencies may include:

• cloud providers;
• payment providers;
• AI model providers;
• authentication platforms;
• databases;
• analytics;
• messaging;
• email;
• open-source packages.

For each important dependency, ask:

• What does it provide?
• How difficult would replacement be?
• What happens if it becomes unavailable?
• Is the pricing predictable?
• Does it create contractual restrictions?
• Is the business dependent on a single provider?

The purpose is not to eliminate dependencies.

It is to understand them.

7. Ownership and Intellectual Property#

One of the most important due-diligence questions is:

Does the business actually control the technology it believes it owns?

Review:

• source repositories;
• domains;
• cloud accounts;
• certificates;
• third-party accounts;
• licenses;
• credentials;
• deployment systems;
• documentation;
• contributor agreements where relevant.

Ownership can be legally complex, so technical due diligence should identify technical facts and questions for legal review rather than replacing legal advice.

8. Technical Debt#

Technical debt is not simply "bad code."

Some technical debt is deliberate.

A startup may intentionally choose a simpler implementation to validate a product quickly.

The important question is:

What consequences will the current technical decisions create as the product develops?

Useful categories include:

• architecture debt;
• security debt;
• infrastructure debt;
• testing debt;
• documentation debt;
• dependency debt;
• operational debt;
• maintainability debt.

A useful report should explain the consequence rather than simply labeling something "technical debt."

9. Scalability#

Scalability should be examined against realistic requirements.

Do not ask:

"Can this handle one million users?"

without defining what those users actually do.

Instead examine:

• expected workload;
• traffic patterns;
• data growth;
• peak usage;
• database behavior;
• external dependencies;
• infrastructure limits;
• cost growth;
• bottlenecks.

A system does not need infinite scalability.

It needs sufficient capacity for its intended requirements with a reasonable path for growth.

10. Team and Knowledge Risk#

Technology can become dependent on a small number of people.

Due diligence should therefore consider:

• who understands the architecture;
• who can deploy the system;
• who handles incidents;
• whether documentation exists;
• whether knowledge is concentrated;
• whether external contractors control important systems.

A technically strong product can still have substantial organizational risk if nobody except one person knows how it works.

11. AI Systems Require Additional Questions#

AI-enabled products introduce additional dependencies and uncertainties.

Review:

• model providers;
• model versions;
• prompts;
• retrieval systems;
• tool permissions;
• data sent to models;
• evaluation methods;
• fallback behavior;
• human oversight;
• model-change procedures.

The important question is not simply:

"Does the product use AI?"

It is:

"How does AI affect the system's behavior, dependencies, cost, security, and operational risk?"

Turning Findings Into Business Meaning#

A due-diligence report should not become a list of technical complaints.

Each important finding should explain:

Technical observation
        ↓
Evidence
        ↓
Potential consequence
        ↓
Business relevance
        ↓
Recommended action

For example:

Observation: Production deployment depends on a single engineer's personal account. Consequence: Access could be lost if that person becomes unavailable. Business relevance: The organization could temporarily lose the ability to deploy or operate the product. Recommendation: Move critical infrastructure and deployment ownership to organization-controlled accounts.

This is much more useful than simply saying:

"Account management is bad."

Common Due-Diligence Mistakes#

Judging technology by the user interface#

A beautiful interface says little about the underlying architecture.

Judging quality by lines of code#

Code volume is not a quality metric.

Treating every dependency as a problem#

Dependencies are normal. Unknown or uncontrolled dependencies are the concern.

Treating technical debt as automatically unacceptable#

Technical debt is often a trade-off. The question is whether its consequences are understood.

Confusing missing evidence with evidence of failure#

If a reviewer cannot verify a control, that does not automatically prove the control does not exist.

Giving false precision#

A risk score can help organize findings, but it should not create an illusion of mathematical certainty.

A Practical Due-Diligence Output#

A useful report can contain:

Final Principle#

Technical due diligence is not about finding reasons to reject a technology system.

It is about reducing uncertainty before an important decision.

A good review should leave decision-makers with a clearer understanding of:

• what they are acquiring or relying on;
• what works;
• what does not;
• what remains uncertain;
• what risks matter;
• what investment may be required;
• and what questions need legal, financial, security, or operational follow-up.

Actionable Checklist#

• Define the business decision driving the review.
• Define the technical scope.
• Collect architecture and repository evidence.
• Review infrastructure and deployment.
• Review relevant security controls.
• Map important dependencies.
• Examine technical debt.
• Review ownership and access.
• Assess key-person and knowledge risks.
• Examine scalability against realistic workloads.
• Evaluate AI-specific dependencies where applicable.
• Separate confirmed findings from missing evidence.
• Explain the business relevance of material findings.
• Document limitations.
• Identify recommended remediation or follow-up work.