Overview
Technical due diligence is the structured assessment of a software company's or product's technical foundations — conducted when an investor, acquirer, or potential partner needs an independent, expert view of what the technology actually is, how well it is built, and what risks and liabilities it carries that are not visible from financial statements or commercial metrics alone.
The gap between a technology company's commercial narrative and the reality of its technical foundations is frequently significant. The "proprietary AI platform" that is a collection of third-party API calls with a thin wrapper. The "scalable cloud architecture" that is a single virtual machine with no redundancy and no monitoring. The "clean, modern codebase" that is six years of accumulated technical debt with no automated testing and a deployment process that requires manual SSH access to production servers. The "experienced engineering team" that is mostly contractors, none of whom have been with the company for more than a year.
Technical due diligence surfaces these realities before an investment or acquisition decision is made, rather than after. The findings influence the valuation — the technical debt that will require remediation investment, the infrastructure that needs to be rebuilt to achieve the scale the acquirer expects, the key-person dependency that means the product does not work without specific individuals who are not contractually committed to stay. The findings also influence the deal structure — the escrow provisions, the earn-out conditions, the representations and warranties that protect against specific technical risks.
Technical due diligence is not a code quality report. It is a business-focused assessment of technical risk and technical value — the technical findings translated into the business implications that inform commercial decision-making. The code quality finding that matters is not that the code does not follow a particular style guide but that the absence of automated testing means that every release carries an unknown probability of introducing regressions, or that the critical business logic is undocumented and understood only by one person who is leaving.
We conduct technical due diligence for investors, acquirers, and strategic partners who need an independent, expert assessment of a technology company's or product's technical foundations — translated into business terms that inform the commercial decision.
What Technical Due Diligence Covers
Technology stack and architecture assessment. The evaluation of what has been built and how.
Architecture overview: the high-level architecture of the system — the major components, the data flows, the deployment infrastructure, the integration points with external systems. The architecture that exists versus the architecture that is described in the target's materials. The architectural decisions that indicate engineering maturity versus the architectural decisions that indicate shortcuts or debt.
Technology choices: the programming languages, frameworks, databases, and infrastructure services used. The choices that are appropriate for the use case versus the choices that reflect historical accident or individual developer preference. The technology stack currency — the frameworks and libraries that are actively maintained and current versus those that are approaching end-of-life or already past it. The technology dependencies that represent vendor lock-in or that have narrow commercial options.
Scalability architecture: the system's capacity to handle the growth that the investment or acquisition thesis anticipates. The current usage metrics, the performance characteristics at current scale, and the bottlenecks that would constrain growth. The architectural changes required to achieve the next order of magnitude in scale — whether those changes are incremental improvements or fundamental redesigns.
Infrastructure and hosting: the cloud or on-premises infrastructure that runs the system. The infrastructure design — redundancy, failover, backup, disaster recovery. The infrastructure cost at current scale and the cost trajectory as usage grows. The infrastructure vendor relationships and contract terms.
Third-party dependencies: the external services, APIs, and libraries that the system depends on. The criticality of each dependency — what breaks if it becomes unavailable. The contractual security of each dependency — whether the availability of the service is guaranteed at the required scale and price. The concentration risk from dependencies on a small number of external providers.
Code quality and engineering practice assessment. The evaluation of how the software is built and maintained.
Codebase assessment: the quality of the code — not as an aesthetic judgment but as a predictor of maintenance cost and reliability. The test coverage that determines whether changes can be made with confidence or whether every change carries unknown regression risk. The documentation that allows engineers who did not write the code to understand and modify it. The code structure that makes it easy or hard to add new capabilities. The debt that has accumulated and the investment required to address it.
Development practices: the processes the engineering team follows. The version control practices — the branching model, the commit practices, the code review process. The testing practices — the unit test coverage, the integration testing, the automated end-to-end testing. The deployment practices — the CI/CD pipeline, the deployment frequency, the rollback capability. The practices that indicate an engineering culture that produces reliable software versus the practices that indicate an engineering culture that produces fragile software.
Security practices: the security posture of the codebase and the development process. The authentication and authorisation implementation. The handling of sensitive data — encryption at rest and in transit, the protection of personally identifiable information, the compliance with relevant data protection regulations. The vulnerability management — the dependency scanning, the penetration testing history, the known vulnerabilities and their remediation status. The access controls — who has access to what, whether access is appropriately limited, whether former employees' access has been revoked.
Intellectual property: the IP ownership of the codebase — whether the company owns the code it has built or whether contractors, former employees, or third parties have claims. The open-source components in the codebase and their licence compatibility with the intended commercial use. The IP that is genuinely proprietary versus the IP that is a combination of publicly available components with thin differentiation.
Engineering team assessment. The evaluation of the people who build and maintain the technology.
Team composition: the size and composition of the engineering team — the ratio of senior to junior engineers, the mix of in-house versus contractors, the distribution of expertise across the stack. The team that can maintain and evolve the system versus the team that is currently keeping the lights on but that cannot support the growth the investment thesis anticipates.
Key-person dependency: the concentration of critical knowledge in specific individuals. The engineer who is the only person who understands how the system's most critical components work. The architect whose departure would leave the team unable to make significant architectural decisions. The key-person dependency that represents a risk if those individuals leave and the mitigations that exist or do not exist.
Retention and continuity: the employment terms and equity arrangements for key engineers. The likelihood that key technical personnel will remain through and after the transaction. The attrition patterns — whether the team is stable or whether there has been significant turnover recently, and what that turnover pattern indicates about engineering culture and team satisfaction.
Hiring capability: the team's ability to hire the additional engineers that growth requires. The locations and hiring markets, the compensation positioning, the employer brand, and the track record of hiring successfully. The team that can grow versus the team that has struggled to hire at current scale.
Product and technical roadmap assessment. The evaluation of the technical feasibility and credibility of planned development.
Current roadmap: the engineering team's current development roadmap — the planned features, the infrastructure investments, the technical debt remediation. The roadmap that is realistic given the team's capacity and capability versus the roadmap that reflects commercial ambition rather than engineering reality.
Technical feasibility of commercial commitments: the technical commitments made to customers, partners, or in the company's sales materials. The feature promised for Q3 that the engineering team does not believe can be delivered in that timeframe. The integration with an enterprise system that has not yet been scoped. The performance guarantee that the current architecture cannot meet. The gap between commercial commitments and technical deliverability.
Technology direction: the technical direction the company is heading and whether it is the right direction. The architectural evolution that is sensible given the market direction and the company's strategic position versus the architectural evolution that reflects internal preferences or sunk cost. The technology investments that will create future advantage versus the technology investments that will create future debt.
Operational maturity assessment. The evaluation of how well the system is operated and how well its operation is understood.
Monitoring and observability: the visibility into system performance and behaviour. The monitoring that tells the team when the system is slow, when errors are occurring, when capacity is constrained. The absence of monitoring that means problems are discovered when customers report them rather than when the system's indicators show them.
Incident management: the process for detecting, responding to, and recovering from production incidents. The incident history — the frequency of incidents, their severity, their root causes, and whether root causes have been addressed or whether the same categories of incident recur. The incident response that is organised and documented versus the incident response that depends on specific individuals who happen to be available.
Deployment and change management: the process for deploying software changes. The deployment frequency, the deployment pipeline reliability, the rollback capability. The deployment process that can deploy multiple times a day with confidence versus the deployment process that requires a scheduled maintenance window and manual steps.
Business continuity: the system's resilience to failures. The availability record — the historical uptime, the downtime incidents, the duration and cause of each. The recovery capability — the backup restoration, the failover, the RTO and RPO that the system can actually achieve versus the RTO and RPO that is stated in documentation.
Compliance and regulatory posture: the compliance requirements applicable to the target's business and how well those requirements are met. The data protection compliance for personal data. The financial services regulatory requirements for fintech products. The healthcare data requirements for health tech products. The compliance gaps that represent regulatory risk and the remediation required to close them.
Intellectual property and data asset assessment. The evaluation of the technical assets that underpin the business value.
Proprietary technology: what is genuinely proprietary about the technology. The algorithm that was developed through significant research investment. The dataset that was assembled over years and cannot be replicated. The integration that took years to build and that represents a genuine competitive barrier. The technology that differentiates versus the technology that is standard implementation that any competent team could reproduce.
Data assets: the data the company has collected and its value. The dataset size and quality. The data that is used in the current product and the data that has potential value in future products or in combination with the acquirer's data. The data ownership — whether the company owns the data or whether customers retain ownership and licensing it back.
Technical moats: the technical barriers to competition that are durable. The network effect that means the product becomes more valuable as more users join. The switching cost that makes it practically difficult for customers to move to a competitor. The scale advantages that mean the product operates more effectively at the company's current scale than a competitor starting from scratch could achieve. The technical moats that will persist after the transaction versus those that are contingent on specific individuals or arrangements.
Due Diligence Process
Information request. The structured request for technical documentation, system access, and engineering team availability. The documentation review that precedes the technical interviews and code access — the architecture documents, the infrastructure diagrams, the security assessments, the incident reports, the engineering roadmap.
Technical interviews. The structured conversations with the engineering team — the CTO or technical lead, the senior engineers, the operations team. The interviews that go beyond the prepared answers in the documentation to understand how the team thinks about the technology, what they know is a problem, and what they are not aware is a problem.
Code and infrastructure review. The access to the codebase and the infrastructure to verify the claims made in documentation and interviews. The code review that focuses on the highest-risk areas identified in the initial assessment. The infrastructure review that verifies the architecture that has been described.
Findings synthesis. The organisation of findings by category and severity — the critical findings that represent deal-changing risks, the significant findings that should influence valuation or deal structure, the observations that provide context without rising to the level of material risk.
Report and briefing. The written report that documents findings with the supporting evidence. The briefing that translates the technical findings into business implications — the technical debt finding expressed as the investment required to address it, the key-person dependency expressed as the retention risk and its probability, the scalability gap expressed as the timeline before the architecture constrains the growth the investment thesis projects.
Calibrating Technical Due Diligence to the Transaction
Technical due diligence scope is calibrated to the transaction type and the specific risks identified in initial assessment.
Series A/B investment: the focus on product-market fit validity, team capability, and the technical foundation for the next stage of growth. The assessment that answers whether the engineering team can build what the product roadmap requires and whether the technical architecture supports the scale the investment is designed to achieve.
Growth equity / Series C+: the deeper assessment of operational maturity, scalability, and the technical debt that constrains velocity. The assessment that answers whether the engineering organisation can scale alongside the business and what investment in technical foundation is required.
Acquisition: the comprehensive assessment that identifies all material technical risks and liabilities. The assessment that informs valuation adjustments, representations and warranties, escrow provisions, and integration planning.
Strategic partnership: the focused assessment of the specific technical capabilities and risks relevant to the partnership terms. The assessment that verifies technical claims and identifies integration risks.
Independent Assessment
The value of technical due diligence is its independence. The target's engineering team has an interest in the transaction completing successfully. The advisor who introduced the deal has an interest in the transaction completing. The technical due diligence advisor has an interest only in providing an accurate assessment — the value that comes from finding problems is equal to the value that comes from confirming strengths.