English for Technical Due Diligence Consultants

Technical due diligence (tech DD) is the process of evaluating the technical health of a software company — typically as part of a merger, acquisition, or investment. The people doing this work — consultants, investors, and technical advisors — need a specific vocabulary for describing what they find and communicating findings to non-technical stakeholders.

For non-native English speakers working in tech DD or being assessed by DD consultants, this guide covers the vocabulary, structure, and phrases you need.

What Technical Due Diligence Covers

A typical tech DD engagement assesses:

• Architecture and scalability — can the system handle growth?
• Code quality and technical debt — how much accumulated risk is in the codebase?
• Security posture — are there known vulnerabilities or compliance gaps?
• Team capability — does the team have the skills to maintain and grow the system?
• Tooling and process — how does the team develop, test, and deploy software?
• Intellectual property — does the company own its code? Are there open-source licence risks?

Core Vocabulary

Architecture Scorecard

An architecture scorecard is a structured evaluation of the system’s technical design against a set of criteria — typically scalability, resilience, security, maintainability, and observability.

“The architecture scorecard shows strong marks for modularity and observability, but identifies significant gaps in disaster recovery planning.”

“We use a 1-to-5 scoring rubric for each dimension of the architecture scorecard.”

Technical Debt

Technical debt in a DD context refers specifically to the accumulated shortcuts, outdated dependencies, and architectural compromises that will require investment to address. It is often categorised by severity.

“The codebase carries significant technical debt concentrated in the payment processing module, which was written in 2018 and has not been substantially refactored.”

“We categorise technical debt into three tiers: critical (blocks growth or creates security risk), significant (slows feature delivery), and cosmetic (style and documentation issues).”

Scalability Risk

Scalability risk is the risk that the current architecture will not support the target company’s projected growth without significant re-engineering.

“The primary scalability risk is the monolithic database — at projected 5x growth, query contention will degrade response times below acceptable thresholds.”

“Scalability risk is rated medium: the architecture can support 3x current load without changes, but a re-architecture will be required before Series B scale.”

Bus Factor

The bus factor (sometimes called “truck factor”) measures how many key people would need to leave the organisation before critical knowledge is lost.

“The bus factor for the core recommendation engine is one — a single engineer holds all institutional knowledge of this system. This represents significant organisational risk.”

Vendor Lock-in

Vendor lock-in is the degree to which the system’s architecture depends on a single vendor’s proprietary services, making migration costly.

“The platform exhibits moderate vendor lock-in to AWS — specifically to DynamoDB and Step Functions, which would require significant re-engineering to replace.”

Open Source Licence Risk

Licence risk arises when open-source components are used under licences that impose obligations on the commercial product — for example, requiring the source code to be made public.

“A dependency audit identified three components licensed under GPL v3. If distributed as part of the commercial product, this could require disclosure of proprietary source code.”

Phrases for Assessment Reports

Summarising Findings

“The overall technical health of the codebase is assessed as medium risk. The architecture is sound for current scale but will require investment ahead of the projected growth trajectory.”

“We identified three critical findings and seven significant findings. The critical findings require remediation before the transaction completes; the significant findings should be addressed within 90 days of close.”

Describing Strengths

“The engineering team has implemented comprehensive automated testing — 87% unit test coverage and a robust integration test suite covering all critical user journeys.”

“The CI/CD pipeline is mature and well-documented, with automated rollback capability and blue/green deployment.”

Describing Risks

“The primary technical risk is the absence of disaster recovery documentation and untested backup restoration procedures.”

“The authentication system relies on a custom implementation rather than an industry-standard library, which increases the risk of undiscovered security vulnerabilities.”

Recommending Actions

“We recommend that the following items be addressed as conditions of close: [list]. We recommend the following items be included in the 90-day post-acquisition integration plan: [list].”

“The acquiring team should plan for a minimum 12-month investment in technical debt remediation and team capability development.”

Phrases for Due Diligence Interviews

If you are being interviewed as part of a DD assessment:

Explaining Architecture Decisions

“We made that architectural choice because [reason]. In hindsight, we would have approached it differently, and we have a plan to refactor it in Q3.”

“That decision was a deliberate trade-off — we prioritised speed to market over architectural purity at the time. The tech debt is known and quantified.”

Acknowledging Known Issues Honestly

“We know we have technical debt in [area]. Here’s our assessment of the risk it poses: [explanation]. And here’s our plan to address it: [plan].”

“Our test coverage is lower than we’d like in the [module] area. We’ve been investing in improving it over the past two quarters.”

Handling Difficult Questions

“That’s a fair question. The honest answer is [X]. I want to be transparent about where we are rather than overstating our maturity.”

Technical due diligence is a high-stakes assessment where language precision matters enormously. Whether you are conducting DD or being assessed, the ability to describe technical systems, risks, and trade-offs in clear English is what enables good decision-making on both sides of the table.