Technical due diligence answers one question: what are you actually buying, and what will it cost to keep running?
We do this for investors, acquirers and boards evaluating an internal programme. It is advisory work rather than delivery, so it is deliberately independent of any build engagement that might follow.
What we assess
Code quality and maintainability. Not a style audit. Whether the codebase can absorb change at the rate the investment thesis assumes, and what it costs if it cannot.
Architecture and scalability. Where the design constrains growth, which limit binds first, and whether the fix is incremental or structural. A system that works at current volume and cannot reach the target is a different risk from one that is merely untidy.
Key-person dependency. How much of the system only one person understands. This is frequently the largest unpriced risk in a small engineering organisation, and it rarely appears in a data room.
Security posture. Dependency currency and known vulnerabilities, secrets handling, authentication and authorisation design, and how data is protected at rest and in transit.
Licence exposure. Open-source licences incompatible with the intended commercial model, which is cheap to find now and expensive to find later.
Data protection. Under GDPR, whether the obligations the business already has are actually met, particularly where personal or special-category data is processed.
Engineering practice. Testing, code review, release process, environments, monitoring and incident response. Practice predicts future delivery cost more reliably than the current state of the code does.
Infrastructure and cost. How it is hosted, what it costs, and how that cost behaves as volume grows.
How it runs
Typically two to four weeks, depending on system size and how much access is available.
We read the code and the infrastructure, interview the engineers who built it, and examine the delivery process as it actually operates rather than as documented. Where access is restricted, which is normal in a competitive process, we say plainly what we could not examine and what that leaves uncertain.
What you get
A written report with findings ranked by severity, each with an estimated remediation cost and a view on whether it is a pre-close issue, a first-hundred-days issue, or something to live with.
We present it to whoever has to act on it, and stay available afterwards for the questions that surface once people have read it. The deliverable is a position you can negotiate on, not a document that gets filed.
What we will tell you plainly
If the system is sound, we will say so, briefly, rather than manufacturing concerns to justify the engagement. And if remediation is the right call but we are not the right firm to do it, we will say that too. Independence is the entire value of this work, and it is worth nothing if the assessment is shaped by wanting the build that follows.
A note on evidence
Unlike the other work described on this site, due diligence engagements are covered by confidentiality that extends well past the usual limits, so there is no case study to link to here and there will not be one.
What we can show is the thinking. The article linked from this page sets out what a useful report contains, how findings should be separated into what changes the price, what belongs in the first hundred days, and what is cheaper to live with, and why an assessor angling for the remediation work is worth very little. Read it and you will know what you would be getting.