The question concerns changeability, tests and specific code issues.
Codebase audit →OXIAE / TECHNICAL CONSULTING
Technical due diligence.
Investigate the technical foundations before an investment or acquisition.
Discuss your projectWhich technical assessment do you need?
You need a review of the system, architecture and operations.
Software audit →An investment or acquisition requires evidence of technical risks.
Technical due diligence (this service)UNDERSTAND THE SERVICE
What does technical due diligence examine in an acquisition?
Technical due diligence tests the technical assumptions behind an investment or acquisition. Alongside code and architecture, I investigate dependencies on suppliers and people, release practices and evidence for scalability claims. The result identifies demonstrated risks, unanswered questions and conditions for subsequent decisions. It is neither a legal assessment nor a guarantee of future performance.
When it is a good fit
A buyer, investor or management team needs to understand the technical obligations and uncertainties associated with a platform.
When to take a different approach
If the question concerns only one module or a remediation backlog, a codebase or software audit is usually more focused. Legal contract and licensing questions require appropriate additional expertise.
PRACTICAL DECISION GUIDE
Technical due diligence makes technical assumptions checkable
Technical due diligence examines the technical basis of a business or product. I turn the assessment question into checkable topics: architecture, development, security, dependencies, operations and continuity. Claims about scalability or transferability are tested where possible against code, configuration, documentation and discussions with accountable people. [1]
The report distinguishes demonstrated facts, team statements and unverified assumptions. Delivery history can show how changes and incidents are managed, but is assessed in context. The result identifies technical issues, assessment limits and follow-up questions; valuation and legal matters require their own specialist assessment. [2][3]
Questions to settle first
- Which technical claim materially affects the proposed decision?
- Which access or evidence is missing to test that claim?
Make acceptance measurable
- An evidence register for major topics with sources, dates and uncertainty.
- A priority overview with technical consequences and focused follow-up questions.
Fictional claim and evidence register — not a transaction assessment
Which technical claim is supported, and which question remains open?
An investor or buyer often receives technical statements, documents and demonstrations that support different levels of certainty. This invented register places a claim, inspected evidence and remaining uncertainty together. It describes neither a business, valuation nor advice on a real investment.
On a narrow screen, scroll the table horizontally to read every column.
| Technical claim | Available example evidence | What does this confirm? | Remaining uncertainty | Suitable follow-up investigation | Who evaluates the next step? |
|---|---|---|---|---|---|
| Another developer can take over and release the product. | A repository and build instructions are available. Only the current lead developer has demonstrated a deployment. | Source code and a documented build route are available; the demonstration shows deployment by that developer. | Independent handover, available permissions, external accounts and knowledge outside the documentation are unverified. | Have a designated successor set up a new test environment and release a version using agreed access. Record missing steps and required authority. | The technical reviewer reports findings; the buyer or investor assesses their meaning for the decision and required conditions. |
| The platform can handle expected growth. | An architecture diagram and a demonstration with few users; no representative load measurement. | The described components and demonstrated scenario are visible. | Capacity, bottlenecks, external limits and recovery under peak load remain unverified. | Define the usage profile and agree a representative capacity exercise covering measurement limits, environment and the exercise's costs. | Technical owners substantiate the exercise; the decision-maker determines how to weigh remaining uncertainty. |
| Data can be recovered after a failure. | Backup-task notices without a complete recovery exercise or subsequent application check. | The notices support execution of the listed tasks. | Completeness, usability, required configuration and achievable recovery time are unconfirmed. | Investigate an authorised isolated recovery exercise with representative data and an agreed user task. | The operator provides evidence; the reviewer describes outcomes and limits; the decision-maker assesses follow-up conditions. |
| Important supplier dependencies are manageable. | An external-service list and some invoices; account ownership, replacement routes and technical limits are incomplete. | The listed services and some current usage are visible. | Continuity after an administrator leaves, access changes or a service fails is unverified. Contractual transferability requires separate assessment. | Check technical account responsibility, access recovery, data export and dependent behaviour during outages. Have appropriate legal expertise assess contract and licensing questions. | Technical and legal reviewers each report within their scope; the buyer or investor makes the transaction or investment decision. |
What this helps you decide
The register prevents a demonstration or team statement from silently becoming evidence for a broader claim. An unverified claim is not a demonstrated defect; it is an information gap or investigation question. This example provides no financial valuation, score, investment advice or guarantee of future performance. Conclusions apply to the inspected evidence, version, environment and date.
Apply this to your own project
- Define the technical assumptions that could materially affect the intended decision; make the scope narrower than 'check everything'.
- For each claim, record source, date or version and evidence type: directly inspected, demonstrated, stated by a team member or not yet supplied.
- Alongside architecture and code, ask about release and recovery responsibility, external services and handover of technical access.
- State missing information explicitly, with an owner and possible next step. Missing evidence does not automatically support a positive or negative conclusion.
- Separate technical findings and investigation limits from legal assessment, financial valuation and the final decision.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Code review | Source-code maintainability is the main question. | Does not provide a complete picture of organisation and operations. |
| Technical due diligence | Technology affects a transaction or investment decision. | Needs evidence from code, operations, documentation and interviews. |
| Architecture consulting | The decision to continue development has been made. | Focuses on future design and migration steps. |
What I need to start
- A bounded investigation question and confidential access to evidence.
- Architecture, release and operational information, including relevant incidents.
- Technical owners available for interviews.
How to assess the result
- Material claims link to evidence or are marked unverified.
- Risks describe impact, dependencies and possible next steps.
- Missing information and investigation limits are visible to decision-makers.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- Platform size and the team and supplier landscape.
- Quality and availability of supplied information.
- Investigation depth and time for interviews and verification.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
An investor or buyer wants to test technical assumptions.
Technical due diligence starts with the technical assumptions behind an investment or acquisition. A software audit can examine the wider solution; a codebase audit provides more detail on code and maintainability. Agree in advance which parts are accessible and which conclusions the available evidence can support.
THE QUESTION I ASK FIRST
Which claims matter to the transaction, and what evidence is available?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
Can you confirm that a platform supports millions of users?
Not from an architecture diagram or code inspection alone. That claim requires representative load tests, capacity information and explicit assumptions about usage.
What if the seller permits only a demonstration?
A demonstration can support the displayed task under the displayed conditions. Without further access, matters such as code quality, operational configuration and independent handover remain only partly testable. The report should attach that limit to the relevant claims; the decision-maker determines whether further investigation or a condition is required.
Does dependence on one developer automatically lead to a negative assessment?
No. Investigate which tasks, permissions and knowledge depend on that person and what handover can be demonstrated. Its significance depends on the product, available alternatives and intended decision. Developer headcount alone does not establish continuity.
Does technical due diligence include a legal opinion on contracts and software licences?
A technical investigation can inventory visible components, services and dependencies and identify questions for follow-up. Legal rights, contractual transferability and licence compliance require appropriate legal assessment. Agree who performs that assessment and what information technical and legal reviewers may share.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- Secure Software Development Framework, SP 800-218NIST
Shared vocabulary for development practices and supplier assessment.
Link and relevance checked: - DORA’s software delivery performance metricsDORA
Contextual assessment of software delivery and instability.
Link and relevance checked: - Application Security Verification StandardOWASP
Framework for scoped verification of application security.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring Technical due diligence? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief