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.

Navigating Nuance: Beyond the Checklist

The core vocabulary – architecture scorecard, technical debt, scalability risk – provides a starting point for understanding the landscape of a technical due diligence. However, truly effective communication during these assessments goes beyond simply naming-these-things; it’s about conveying the impact and suggesting potential solutions with precision. A critical element often missed is acknowledging subjective judgment within an objective framework. For example, even a seemingly straightforward “high” architectural score doesn’t automatically justify significant rework – it needs to be contextualized. Phrases like “While the current architecture presents challenges regarding maintainability…” are far more effective than simply stating “Architecture Score: High.” Similarly, quantifying technical debt isn’t about assigning an arbitrary number; it’s about articulating the cost – in terms of development time, potential future issues, or increased risk - associated with that debt. Focusing on tangible consequences is key to influencing decision-making during a due diligence process.

Furthermore, remember that these assessments are rarely purely technical. Stakeholder alignment and buy-in are crucial. Phrases like “From a scalability perspective…” can easily sound dismissive of other concerns if not carefully framed. Shifting the focus to “Considering potential scaling bottlenecks… we recommend prioritizing…” demonstrates collaboration and proactively addresses risks. The ability to clearly articulate these nuanced considerations, especially in less formal settings like Slack channels, is paramount. A simple “This PR introduces significant technical debt – needs careful review” will likely be met with resistance; a more constructive approach - “The current implementation deviates from established architectural guidelines, potentially increasing long-term maintenance costs and introducing scalability risks. Let’s discuss mitigation strategies during the code review.” - is far more effective in fostering discussion and driving action.

Finally, remember that documentation – particularly PR descriptions – needs to be clear, concise, and persuasive. It’s not just about stating what was changed; it’s about explaining why, highlighting any associated risks, and suggesting necessary follow-up actions. This requires a shift in mindset from simply documenting the code to articulating its implications within the broader system context.

# Example: Identifying potential performance bottlenecks using `perf` on Linux
perf top -p 12345  # Replace 12345 with the process ID

This command, while simple, exemplifies a key skill – the ability to translate technical observations into actionable insights. The report generated by perf isn’t just raw data; it’s evidence that can be used to justify investment in architectural changes or further investigation. Mastering this translation is what elevates due diligence assessments from purely diagnostic exercises to impactful strategic recommendations.