The question concerns changeability, tests and specific code issues.
Codebase auditBLACKOPS SOFTWARE / 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 auditAn 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, we 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.
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 we 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. We 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.
01 / PROBLEM & POSSIBILITIES
Your challenge.
A practical application.
An investor or buyer wants to test technical assumptions.
Investigate the technical foundations before an investment or acquisition. We agree what the solution should do, which information it needs and how the result will be assessed.
THE QUESTION WE ASK FIRST
Which claims matter to the transaction, and what evidence is available?
02 / FROM QUESTION TO SOLUTION
An approach with
clear steps.
You stay informed about decisions, progress and delivery. We adapt the scope to your organisation.
Agree the question and scope
Which claims matter to the transaction, and what evidence is available?
Examine evidence and dependencies
We use representative examples and discuss the results, making assumptions and limitations visible before proceeding.
Discuss findings and priorities
We document the agreed outcomes, responsibilities and next steps.
03 / A PRACTICAL FOUNDATION
Designed for your
systems and requirements.
Technology that fits
Code, architecture documentation, test results, infrastructure information and discussions with your technical team.
Security and control
We agree the investigation boundaries and access in advance. Findings distinguish demonstrated risks from issues requiring further investigation.
A possible application
An investor or buyer wants to test technical assumptions. The project can start with one focused component. Together we assess whether expanding it makes sense.
Illustrative scenario; not a published client case.04 / WHAT TO EXPECT
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.
Where do we start with technical due diligence?
Which claims matter to the transaction, and what evidence is available? We discuss this together, define the scope and establish what is needed for an informed proposal.
What does the project cost?
The investment depends on scope, existing systems, data quality and required integrations. Your proposal separates the work, assumptions and any recurring usage or operating costs. A useful estimate requires an understanding of your situation.
How long does delivery take?
We agree a schedule once the scope and dependencies are known. System access, team availability and acceptance testing are included in the plan. Where possible, we start with a focused first step.
Can we keep our existing systems?
Code, architecture documentation, test results, infrastructure information and discussions with your technical team. We investigate the possibilities and limitations before proposing a technical approach.
What happens after delivery?
You receive a handover explaining the solution and its documentation. Maintenance, support and further development are agreed separately, including responsibilities and how errors will be handled.