Repository, commit, branch and build
Separate code state from build capability.
Short answer: For investors, technical due diligence is tailored to the specific transaction context. It examines supportable technical substance, risks, dependencies and open points without pre-empting the investment, valuation or legal decision.
Examine technical reality rather than product narrative
In technology-driven transactions, the relevant question is which technical state actually exists and can be evidenced. This includes codebase, architecture, build and deployment capability, security, technical debt, key dependencies and relevant data or AI components.
The review is not intended to create a positive or negative investment narrative. It classifies technical strengths, risks, uncertainties and open evidence so investors can combine them with their own economic and strategic criteria.
Typical reasons for an assignment
- before an initial or follow-on investment in a software- or data-driven company
- during buy-side or M&A review where codebase, architecture, security and delivery risks require independent examination
- when the pitch deck contains material technical claims whose evidence must be checked in the data room
- when technical debt, scalability assumptions, key dependencies or AI components may be material to the investment thesis
Typical technical questions
- Which codebase and production system states actually exist and can be reproduced?
- How robust are architecture, build, test, release and deployment processes?
- Which technical debts, key dependencies or single points of failure exist?
- Which security, data or AI risks are technically supported and which are assumptions?
- Which missing evidence could materially change the technical risk assessment?
Examination scope: Technical due diligence evaluates the examined technical state. It does not replace company valuation, investment decisions, IP legal review, tax, financial or legal due diligence.
From transaction context to supportable technical risk classification
Investor examination chain
From transaction context to supportable technical risk classification
2
Preserve technical evidence
Attribute repositories, builds, releases, architecture and operating evidence reliably.
3
Test risks
Examine technical debt, dependencies, scalability assumptions and alternative explanations.
4
Bound the synthesis
Classify findings, uncertainty and technical options by evidence and materiality.
Technical maturity is not company value. The investment decision remains with the investor.
Typical examination material
- Repositories, commit and branch histories and build artefacts
- Architecture records, interfaces, infrastructure and deployment configuration
- Test, QA, release and monitoring evidence
- Dependency lists, patch states, security and incident records
- Data pipelines, model artefacts, training/test data and AI operating documentation where relevant
What you receive
- a technically prioritised risk classification tied to the artefacts actually reviewed
- an overview of architecture, code/build capability, delivery, security, dependencies and, where relevant, data/AI components
- clear identification of material evidence gaps, assumptions and claims that cannot be verified reliably
- a technical summary for the transaction context; no company valuation or go/no-go investment recommendation
Relevant service areas
Technical Due Diligence
Software & Source Code Assessment
IT Security Assessment
Data & AI Assessment
Relevant knowledge for preparation and deeper review
Test, QA and release evidence
Reconstruct quality assurance and delivery states.
Dependencies and security updates
Examine component risks and patch states over time.
Validate an ML model
Examine model quality, validation design and statement boundaries.
LLM systems as a subject of examination
Separate model, prompting, RAG, tools and system context.
Reconstruct data lineage
Trace provenance and transformations of decision-relevant data.
Statement and decision boundary: Technical due diligence describes technical strengths, risks, dependencies and uncertainties. It does not provide a buy, sell or invest recommendation and does not determine company value or legal ownership rights.
Frequently asked questions
Can due diligence be useful with an incomplete data room?
Yes, but the strength of the conclusions depends on the available scope. Missing repositories, builds, operational data or security evidence are treated as open evidence rather than automatically positive or negative findings.
Does high test coverage automatically indicate technical maturity?
No. Coverage is only one indicator. Its meaning depends on test quality, relevance, build/release process, architecture and actual operating state.
Does technical due diligence evaluate the investment case?
No. It provides a technical decision basis. Economic evaluation, market assumptions and the investment decision remain with the investor.
Prepare the technical due diligence scope
For an initial review, the transaction stage, technical investment hypotheses, desired examination depth and expected data-room artefacts are useful. The technical scope is adapted to materiality and available evidence.
Send enquiry