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 companyThe valuation depends on what the platform really is.
Bolt-ons
Integrating a platformYou need to know whether integration is straightforward — or a rebuild.
Divestments
Preparing for a saleKnow what the buyer’s advisers will find before they do.
Post-close
Inheriting a platformUnderstand what you now own — and what it will take to change.
How it works in a deal
01
LOI + data roomA deck, and a repository nobody on your side has read.
02
Technical due diligenceRead the code. Verify the claims. Price the fixes.
03Decide
ProceedEvidence supports the deal.
RepriceRisk changes the economics.
Walk awayWhen that is the answer, we say so.
If you proceed
04
Post-close planThe 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 diagramA modern, scalable platform.
Reported test coverageHigh test coverage and a mature release process.
Licence scheduleA clear and compliant licence position.
Team descriptionAn experienced and stable team.
What the code shows
The system as built
Actual architectureThe real architecture, and where it departs from the diagram.
Tests actually runningWhat is tested, how, and what is not.
Dependencies actually usedThird-party and open-source licences in the code.
Key-person dependencyHow much the system depends on one or two people.
Our process
01
ReadThe repository and its history.
02
VerifyEvery claim against what the code shows.
03
PriceThe fixes, the integration effort, the key-person risk.
04
DecideProceed, 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.
Real systems. Real outcomes.
01Architecture 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 builtThe architecture as it exists in the code. Services, components, interfaces and infrastructure.
Where reality departs from the deckDifferences between the documented and actual system. Undocumented components, workarounds and technical debt.
What that means for the dealIntegration 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.
02Data 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 builtHow the data is structured in the code, including key entities, relationships and constraints.
Data quality and integrityWhat is duplicated, what is missing, what is inconsistent, and how the system handles it in practice.
Implications for the dealThe 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.
03Code 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 practiceWe assess code structure, complexity and maintainability, looking at real code, not just metrics or claims.
Tests and quality gatesWhat is actually tested, how tests are run, and how much confidence the test suite gives in making changes.
Release process and change riskHow 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.
04Security 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 practiceThe controls that exist, and the ones that do not. How the system handles authentication, authorisation, secrets and data.
Third-party and open-source licencesThe licences actually used in the code, including versions, obligations and any copyleft or commercial restrictions.
What this means for the dealThe 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.
05People, 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 dependencyHow much of the system depends on one or two individuals, what they work on, and whether that knowledge is documented.
Suppliers and external servicesWhich third-party services and suppliers the platform depends on, what each one provides, and whether there are realistic alternatives.
Contracts and renewalsWhich 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.
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
45 minutes · no charge
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.
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
01
Scope the diligenceConfirm the transaction, access, timetable and the questions the investment decision needs answered.
You getA defined scope, timetable and fee.
02
Read, verify & priceRead 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.
03
Decision reportTurn 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. OptionalUse the diligence as the starting point for a Modernization Specification or Gated Rebuild — without paying to rediscover the same system.
Read first. Then decide.
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.
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+ yearsTechnology leadership
5 countriesUK · Spain · Italy · Colombia · USA
Acquirer-sideTechnical due diligence
02
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 closeAn acquisition, a bolt-on, a sale, or a system that becomes yours at close.
A codebase you can give us access toThe repository and its history, not a description of them.
A decision that depends on the answerThe price, the earn-out or the integration plan rests on what the code is.
A board or investment committee that will read the reportWritten 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 makeBefore 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 repositoryOur conclusions come from the code and its history, not from assumptions or presentation material.
When you need more than a security testWe look at architecture, data, maintainability, dependencies, cost-to-fix and integration effort — not security in isolation.
When there is a real system to assessWe 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 expertsFocused on your system and your goals.
Practical input from experienced engineersReal-world perspective, not a sales deck.
Clear next stepsYou’ll know whether there is work here and what happens next.