Technical Due Diligence
That Says What Changes the Deal
Before you invest in a software business or buy one, someone senior should read the code, look at how it runs, and talk to the people who built it. We do that independently and report back in plain language: what you are buying, what it will cost to fix, and which of the problems should change your price or your decision.
Quick Take
Technical due diligence is an independent review of a company's software, infrastructure, security and engineering team before an investment or acquisition. A standard assessment takes two to three weeks and is quoted as a fixed fee, typically between £5,000 and £25,000 depending on the size of the estate. The useful output is not a list of problems, because every software company has those. It is a ranking that tells you which findings threaten the investment case, which belong in the price or the completion conditions, and which are ordinary debt to budget for afterwards.
The Question the Report Has to Answer
An investment committee reading a technology report wants one of three answers: proceed, proceed on different terms, or walk away. A report that lists thirty observations at equal weight leaves the committee to work that out for itself, which is the work it paid someone else to do.
So every finding we report carries a classification as well as a severity:
Threatens the thesis
The business plan assumes something the technology cannot do, or there is an exposure large enough that no price adjustment covers it. Rare, and we say so plainly when we find one.
Belongs in the terms
A real cost or risk that can be priced, warranted, or made a condition of completion: a key engineer who needs a retention agreement, a licence position that needs fixing before signing, a security gap the seller should close first.
First hundred days
Work the new owner should plan and fund soon after completion. Costed as a range, sequenced, and written so it can become the start of the technology roadmap.
Ordinary debt
The shortcuts any company of that size and age carries. Noted so nobody is surprised later, and explicitly marked as not a reason to change the deal.
The last category matters more than it looks. Assessors who are paid by the number of problems they find, or who hope to win the clean-up work, tend to promote ordinary debt into risk. That makes the report look thorough and the deal look worse than it is.
What Findings Look Like
The kind of thing a technical assessment turns up, and how each would be classified. None is unusual.
One engineer holds the keys
The billing integration and production database access sit with a single long-serving developer, and nothing about either is written down. Terms: a retention and handover arrangement before completion, and a documented second person with access.
Customer data on laptops
Copies of the production database are used for testing on developer machines. It is convenient and common, and it is a personal data exposure under UK GDPR. Terms: the seller stops it and deletes the copies before signing.
A framework out of support
The core application runs on a framework version that no longer receives security patches. The upgrade is understood work, not a rewrite. First hundred days: costed at a range of engineer-weeks, scheduled early.
A copyleft library in the product
An AGPL-licensed component is built into software the company distributes to customers. Depending on how it is used, this ranges from a quick replacement to a disclosure obligation on proprietary code. Terms, sometimes thesis: legal opinion before signing.
The AI feature is someone else's
The capability the pitch deck calls proprietary AI is a prompt sent to one model provider, on standard terms the provider can change. Valuation question: the feature may still be valuable, but the moat is not where the deck says it is.
Thin tests on stable code
Automated test coverage is low, but almost entirely in modules that have not changed for years and do not cause incidents. Ordinary debt: worth improving where the roadmap will touch the code, not a reason to move the price.
The same finding can land in different categories in different deals. A single engineer holding critical knowledge is a terms issue in a growth investment where they are staying, and a thesis issue in an acquisition where they have already said they will leave.
How the Two to Three Weeks Run
- ✔ Scoping, day one. A call with the deal team to understand the investment case, the timetable and what is already worrying you. The scope follows the thesis: a buy-and-build platform deal needs a different emphasis from a minority growth round.
- ✔ Access and documents, days one to three. Read-only access to the code repositories and cloud accounts, plus whatever architecture and security documentation exists. How long the target takes to provide this, and whether they can produce an accurate list of their own systems, is itself a finding.
- ✔ The code and the infrastructure, days three to eight. Commit history, tests on the paths that carry revenue, dependency and licence position, the deployment pipeline, how production is monitored and backed up, and how access is controlled.
- ✔ Interviews, days eight to eleven. Usually three to five conversations with the CTO, engineering leads and one or two engineers. These come after the code on purpose: knowing what the repository says makes it clear which answers to probe.
- ✔ Writing, then presenting. The report is written in one pass so it has an argument rather than a list, then presented live to the investment committee or board.
Compressed timetables are possible inside a tight exclusivity period. We will tell you at scoping which parts of the coverage a shorter timetable gives up, so the decision to compress is yours rather than a silent gap in the report.
The work is remote by default and conducted under NDA. The target does not need to install anything or give write access to any system.
What You Receive
A written report, typically twenty to thirty pages, built to be read at three depths:
- ✔ Executive summary, one to two pages. The answer to the proceed, renegotiate or walk away question, and the three to five findings that drive it.
- ✔ A red, amber and green scorecard across architecture, code, security and licensing, infrastructure and operations, and team, so the shape of the risk is visible at a glance.
- ✔ The findings register. Each finding with its evidence, severity, classification and an estimated remediation cost as a range.
- ✔ A sequenced hundred-day plan for the new owner, written as work to be done rather than a list of complaints.
- ✔ A live session with the investment committee or board, where findings can be challenged and answered directly.
The full list of questions we work through in each area is published in our technical due diligence checklist. It is public so you can judge the scope before speaking to us, and so a target can see what they will be asked.
What AI Has Added to the Scope
Two years ago an assessment rarely needed to ask about AI. Now almost every target uses it somewhere, either in how the team writes code or in the product itself, and both create questions an investor should have answered:
- ✔ How AI-written code is reviewed. Teams using coding assistants ship faster, but if nobody reviews the output properly, defects and security weaknesses build up quietly. Commit history and review records usually show which kind of team it is. Our guide to reviewing AI-generated code sets out what good practice looks like.
- ✔ Where company and customer data goes. Which AI tools staff use, what is sent to them, and whether the vendor terms allow that data to be retained or used for training.
- ✔ Dependence on model providers. What happens to margins if a provider raises prices, and to the product if a model is withdrawn. A business built on one provider's API with no fallback carries a concentration risk the financial model may not show.
- ✔ Regulatory classification. Whether an AI feature falls into a category with obligations under the EU AI Act, which matters for any target with EU customers whether or not it is based in the EU.
Where the technical assessment ends and the legal one begins is covered in our article on AI compliance in due diligence. In short, we establish the facts about what the system does and where data flows, and the lawyers advise on what those facts mean.
Investors, Acquirers and Founders
VC and growth investors
The question is usually whether the platform and team can support the growth the round is funding. Emphasis on scalability, delivery capability, key people and how far the product is from the roadmap in the deck.
Private equity and trade acquirers
Here the emphasis moves to liabilities and integration: licence position, security history, the cost of bringing the estate to the acquirer's standards, and what breaks if the founding engineers leave after the earn-out.
Corporate finance advisers
An independent technical workstream alongside your financial and legal diligence, written so its conclusions slot into the overall report rather than sitting in an appendix nobody reads.
Founders preparing to raise or sell
A readiness review of one to two weeks before investors arrive. You get the same assessment a buyer would commission, ranked by what they will ask about first, while there is still time to fix it on your own terms.
Cost and Independence
Assessments are quoted as a fixed fee once the scope is known, typically between £5,000 and £25,000. The fee depends on the size and number of codebases, how many products or platforms are in scope, how deep the security review needs to go and how compressed the timetable is. It does not depend on deal value. Day rates sit in the same range as our fractional CTO work.
We do not sell implementation off the back of a report, and we take no position that depends on the deal completing. If the deal goes ahead and you want help with the hundred-day plan, that is a separate decision made after the report is accepted, never a reason to shape it.
The assessment is carried out by Rafal Skucha, who has held CTO and Head of Technology roles in fintech, e-commerce and media, not by an analyst working through a questionnaire. Judging whether an architecture will survive three years of growth, or whether a team can run what it has built, depends on having been responsible for those outcomes.
When You Do Not Need One
A full assessment is not always worth the fee. For a pre-seed company with a prototype and one developer, a half-day conversation and a look at the repository answers most of what an investor needs to know. If your own CTO or a portfolio company's engineering team can do the review and has no stake in the outcome, use them, and bring in an outside view only for the areas they are less sure of. We will tell you on the first call if either applies.
Common Questions
Does the target company know the review is happening?
Yes. A useful assessment needs read-only access to code and infrastructure and time with the engineering team, which the target has to agree to. The scope and the timetable are usually agreed between the deal team, the target and us on the first day.
Can you review a company whose code we cannot see?
Partly. Without code access the review relies on documents, demonstrations and interviews, which is closer to a structured conversation than an assessment. We will say in the report what could not be verified, and we would advise making code access a condition of the next stage.
Do you work on deals outside the UK?
Yes. Most of the work is remote, and we take on assessments of companies in the UK, Europe and the US, including UK and EU businesses preparing for US investors who expect SOC 2 and similar questions to be answered.
What happens after the report?
The report and the live session are the end of the engagement. Some clients ask us to oversee the hundred-day plan afterwards as a fractional CTO, but that is agreed separately and never assumed.
Have a Deal on the Table?
A free half-hour call. Tell us about the target and the timetable, and we will tell you what an assessment would cover, what it would cost and whether you need one at all.