ServicesTechnical Due Diligence

Read the code
before you sign.

We inspect the repository — not the seller’s deck.

We tell you what the platform is, where the risk sits and what it will cost to fix. The output is a clear, board-ready report.

  • Read the evidence Code, architecture and repository history.
  • Quantify the risk What matters, what it will cost to fix.
  • Make the decision A board-ready view you can defend in the room.

If the evidence says walk away, we say so.

A common deal situation

The deal rests on a codebase.
You need independent technical judgement on your side.

The code deserves independent scrutiny — whether you’re buying, integrating, selling or already closed, the question is the same.

  • Acquisitions

    Buying a company The valuation depends on what the platform really is.
  • Bolt-ons

    Integrating a platform You need to know whether integration is straightforward — or a rebuild.
  • Divestments

    Preparing for a sale Know what the buyer’s advisers will find before they do.
  • Post-close

    Inheriting a platform Understand what you now own — and what it will take to change.

How it works in a deal

  1. LOI + data room A deck, and a repository nobody on your side has read.
  2. Technical due diligence Read the code. Verify the claims. Price the fixes.
  3. Decide

    • ProceedEvidence supports the deal.
    • RepriceRisk changes the economics.
    • Walk awayWhen that is the answer, we say so.
Post-close plan The findings become the first technology plan.

Every deal comes down to three questions.

  • What is it? What have you actually been shown?
  • Where is the risk? Architecture, security, maintainability, dependencies.
  • What will it cost? To integrate, stabilise or replace.

The deck can’t answer those questions.
The repository can.

How we do technical due diligence

The deck is not the codebase.
We read the codebase.

We verify what you’re being told against what was actually built.

What you’re told

The system as described

  • Architecture diagram A modern, scalable platform.
  • Reported test coverage High test coverage and a mature release process.
  • Licence schedule A clear and compliant licence position.
  • Team description An experienced and stable team.

What the code shows

The system as built

  • Actual architecture The real architecture, and where it departs from the diagram.
  • Tests actually running What is tested, how, and what is not.
  • Dependencies actually used Third-party and open-source licences in the code.
  • Key-person dependency How much the system depends on one or two people.

Our process

  1. Read The repository and its history.
  2. Verify Every claim against what the code shows.
  3. Price The fixes, the integration effort, the key-person risk.
  4. Decide Proceed, reprice or walk away, in writing.
The output isn’t a technical report for its own sake. It’s evidence for a deal decision.

What we examine

Six things the deck cannot tell you.
The repository can.

We verify the seller’s claims against the repository and its history, area by area, and we price what we find.

Architecture as built

The system, not the diagram.

We read the repository first, then compare what was actually built with the architecture you were shown.

  • What was actually built The architecture as it exists in the code. Services, components, interfaces and infrastructure.
  • Where reality departs from the deck Differences between the documented and actual system. Undocumented components, workarounds and technical debt.
  • What that means for the deal Integration effort, technical risk and the likely cost of change. What you can reuse, what needs to be reworked, and what could slow you down.

What you getA clear view of the architecture you are actually buying — and what it will take to integrate it.

Data model and data quality

What migration and integration really involve.

We map the data model as it exists in the code and assess the quality of the data, so you know what it will take to integrate, migrate or replace the system.

  • The data model, as built How the data is structured in the code, including key entities, relationships and constraints.
  • Data quality and integrity What is duplicated, what is missing, what is inconsistent, and how the system handles it in practice.
  • Implications for the deal The effort and risk involved in migration or integration, and any data that would need to be cleaned, transformed or rebuilt.

What you getA realistic view of the data you are actually buying — and what it will take to make it work for you.

Code quality, tests and releases

How safely the system can change.

We examine the code, the tests and the release process as they actually exist in the repository, not as they are described in the deck.

  • Code quality in practice We assess code structure, complexity and maintainability, looking at real code, not just metrics or claims.
  • Tests and quality gates What is actually tested, how tests are run, and how much confidence the test suite gives in making changes.
  • Release process and change risk How the system gets to production, how often, and what it would take to make changes safely — including the likely cost and effort.

What you getA clear view of how safely the system can evolve — and what it will take to make changes.

Security posture and licences

What risk and obligations transfer at close.

We review the actual controls in the code and infrastructure, and the third-party and open-source licences as they are used, not as declared, so you know what you are taking on.

  • Security posture in practice The controls that exist, and the ones that do not. How the system handles authentication, authorisation, secrets and data.
  • Third-party and open-source licences The licences actually used in the code, including versions, obligations and any copyleft or commercial restrictions.
  • What this means for the deal The risks, remediation effort and any obligations that will transfer to you at close.

What you getA clear view of the security and licensing position you are actually buying — and what it will cost to stay compliant.

People, key-person and supplier dependencies

What the system depends on to keep running.

We analyse the team, external suppliers and key individuals in the code and operational setup, so you know what would be hard to replace, what each supplier provides, and what it would take to keep the system running.

  • Key-person dependency How much of the system depends on one or two individuals, what they work on, and whether that knowledge is documented.
  • Suppliers and external services Which third-party services and suppliers the platform depends on, what each one provides, and whether there are realistic alternatives.
  • Contracts and renewals Which contracts, licences and supplier agreements come with the deal, when they renew, and what the risks are if terms change or a supplier is lost.

What you getA clear view of the people and suppliers the system relies on — and the risk, cost and effort involved if they change.

So you can decide

  • Proceed With confidence.
  • Reprice With evidence.
  • Walk away When the risks outweigh the value.
Delivered through The Five Gates

From first call to a decision

A clear path from the first conversation to a decision.

Start with a 45-minute Technical Review Call. If there is a fit, we scope the diligence. Each stage produces something useful — and you can stop when you have what you need.

Step 0 · Entry point

Technical Review Call

We understand the deal, the timetable and what technical access is available.

You leave with

A clear view of whether Technical Due Diligence is the right next step.

Book a Technical Review Call No charge. 45 minutes.
You know the scope before the work starts. Every diligence is scoped around the deal, the codebase and the decision you need to make. Scope, timetable and fee are agreed before we begin.

If the deal proceeds

Codebase Due Diligence fees are credited in full against a Modernization Specification or Gated Rebuild started within 60 days.

Read first. Then decide.

Technical Due Diligence

  1. Scope the diligence Confirm the transaction, access, timetable and the questions the investment decision needs answered.

    You getA defined scope, timetable and fee.

  2. Read, verify & price Read the repository and its history. Test the seller’s claims. Identify the risks and price what they mean.

    You getEvidence, not another description of the platform.

  3. Decision report Turn the findings into the language the board or investment committee needs.

    You getWhat the platform is. Where the risk sits.
    What it costs. What we recommend.

If the deal proceeds

Carry the findings forward. Optional Use the diligence as the starting point for a Modernization Specification or Gated Rebuild — without paying to rediscover the same system.

Who does the work

The person who reads the code
has sat on the acquirer’s side of the table.

We bring first-hand acquisition experience and engineering evidence to every review.

See all engagements

Acquirer-side experience

Director of Technology for a private-equity software group

Full-time role

Technical due diligence on acquisition targets was part of the role — reading the code, testing what the seller described and assessing what the business was actually buying.1,2

  • 20+ years Technology leadership
  • 5 countries UK · Spain · Italy ·
    Colombia · USA
  • Acquirer-side Technical due diligence

Our own delivery tooling

How we separate evidence from judgement.

Founder-built
The method

Our review tooling separates evidence from judgement. Static analysis reads the code and its history; language models reason over that evidence; a hard gate checks the result before it reaches the report.

What that means for the report
  • Static analysis produces the evidence.
  • A model reasons over it, never asserts around it.
  • A hard gate sits between the two.

First live run

Two of four reviewer agents were caught fabricating commit hashes.

1 Founder CV, Profile and Core Expertise. 2 Founder CV, Director of Technology entry.

A good fit looks like this

A live deal.
A codebase we can read.

We help when there is a real transaction, access to the repository, and a decision that depends on what the code shows.

  • A live deal, or a platform inherited at close An acquisition, a bolt-on, a sale, or a system that becomes yours at close.
  • A codebase you can give us access to The repository and its history, not a description of them.
  • A decision that depends on the answer The price, the earn-out or the integration plan rests on what the code is.
  • A board or investment committee that will read the report Written to be read in one sitting and defended in the room.

Where we add value

When the code can
change the decision.

We are most useful when independent technical evidence can still affect what happens next.

  • While there is still a decision to make Before signing or after close, our work matters when what we find can change whether you proceed, reprice or adjust your integration plan.
  • When we can inspect the repository Our conclusions come from the code and its history, not from assumptions or presentation material.
  • When you need more than a security test We look at architecture, data, maintainability, dependencies, cost-to-fix and integration effort — not security in isolation.
  • When there is a real system to assess We focus on operating software businesses where the code informs a real investment decision.

Get started

Have a deal or platform to assess?

Start with a 45-minute Technical Review Call, at no charge. We’ll look at the deal, the code access available and the decision you need to make — then tell you whether we can help and what the right next step is.

  • Technical discussion with senior experts Focused on your system and your goals.
  • Practical input from experienced engineers Real-world perspective, not a sales deck.
  • Clear next steps You’ll know whether there is work here and what happens next.
Book a Technical Review Call

45 minutes. No charge. No sales deck.