Technical due diligence for investors
Independent technical due diligence for investors
Independent technical due diligence for venture capital, private equity, family offices, syndicates and trade acquirers, at four levels: a graded technology and operations review, a code and platform audit, both combined and reconciled, and an on-site review. The question is not whether the code is good. It is whether the technology supports the investment thesis, what could change the deal economics, and what has to happen in the first hundred days.
Former CTO and COO, founder of my own consultancy since 2014. I hold no development capacity to sell you afterwards and take no supplier referral fees, so the report serves your decision and nothing else.
Findings are graded, anything taken on the company's word is labelled as stated rather than verified, and anything that could not be examined is listed as not assessed.
The decision the report has to support
A diligence report that only grades the codebase leaves you to work out what it means for the deal. These are the three questions the work is built around.
Does the technology support the investment thesis?
Whether the platform, the architecture and the team can actually deliver the plan the valuation assumes, or whether the plan quietly needs a rebuild first.
What could change the economics?
The costs that surface after completion: re-platforming, licence and infrastructure commitments, remediation, hires the business has been doing without, and suppliers who hold the leverage.
What has to happen after the deal?
A sequenced view of what must be fixed before scale, what can wait, and what belongs in the first board pack as a standing item.
Who it is for
Venture capital
A seed or series A target where the platform, the team and the delivery record have to support the growth case you are underwriting.
Private equity
A buy-and-build or growth deal where technology cost, integration effort and supplier lock-in move the model rather than the headline.
Family office and angel syndicates
A single senior technologist to read the technology on your behalf, without a fund-sized diligence budget or a panel of advisers.
Trade acquirers
An acquisition where you inherit the estate, the people and the technical debt, and need to know the first hundred days before you sign.
Four levels of assurance
The levels are not four flavours of the same report. They differ in what the findings are based on, and that is what decides how much weight you can put on them.
Level one
Technology and operations review
Board and investor level. Each area is graded for likelihood and seriousness so the whole estate can be read on one page, with the rating scale explained in the report rather than left as a colour.
- What it answers
- Is there anything in how this technology function is run that changes the deal?
- What it is based on
- Management interviews, documentation, policies and what the company chooses to show.
- What it cannot tell you
- It cannot be independently validated. If the picture presented is incomplete or optimistic, a high-level review will not catch it.
- When to choose it
- A pre-offer read, or a business that happens to use software rather than sell it.
Level two
Code and platform audit
The technical pass, area by area, with every finding traced back to the file, configuration or environment it came from and taken through four verification stages before it reaches you.
- What it answers
- What is actually there, and what will it cost to put right?
- What it is based on
- The codebase, configuration, environments and, where access allows, running behaviour.
- What it cannot tell you
- It reads the artefact, not the organisation. Delivery habits, governance and key-person dependency sit outside its evidence base.
- When to choose it
- Deals where the software is the asset being bought.
Level three
Recommended for a deal
Combined review and audit
Levels one and two run together, then reconciled. What management stated is tested against what the code shows, and every gap between the two is reported as a finding in its own right with the evidence for both sides set out.
- What it answers
- Does the account we have been given hold up against the system, and where does it not?
- What it is based on
- Both evidence bases, cross-checked against each other.
- What it cannot tell you
- It still relies on the access granted. Anything the target will not open is listed as not assessed.
- When to choose it
- The default for a transaction. It is the only level where the management narrative is validated rather than recorded.
Level four
On-site technical due diligence
Level three plus time in the building: sessions with the engineers, sight of the working cadence, and the conversations that do not happen on a scheduled call.
- What it answers
- Can this team deliver the plan, and who is the business quietly dependent on?
- What it is based on
- Everything above, plus direct observation of the team and how decisions get made.
- What it cannot tell you
- It needs the target's cooperation and enough time in the diary. Travel is scoped and costed per engagement.
- When to choose it
- Larger deals, distributed estates, and any case where the people are as material as the platform.
| Level | Evidence base | What it proves | Limits |
|---|---|---|---|
| Level oneTechnology and operations review | Management interviews, documentation, policies and what the company chooses to show. | Is there anything in how this technology function is run that changes the deal? | It cannot be independently validated. If the picture presented is incomplete or optimistic, a high-level review will not catch it. |
| Level twoCode and platform audit | The codebase, configuration, environments and, where access allows, running behaviour. | What is actually there, and what will it cost to put right? | It reads the artefact, not the organisation. Delivery habits, governance and key-person dependency sit outside its evidence base. |
| Level threeCombined review and audit | Both evidence bases, cross-checked against each other. | Does the account we have been given hold up against the system, and where does it not? | It still relies on the access granted. Anything the target will not open is listed as not assessed. |
| Level fourOn-site technical due diligence | Everything above, plus direct observation of the team and how decisions get made. | Can this team deliver the plan, and who is the business quietly dependent on? | It needs the target's cooperation and enough time in the diary. Travel is scoped and costed per engagement. |
Why a review on its own is not validation
A level one review is built from what the company supplies: interviews, documentation, policies and the parts of the estate it chooses to show. It is genuinely useful at board level, and it is honest about what it is. It is not validation. If the account given is incomplete, or better than the reality, a high-level review has no way of knowing.
Level two is the opposite problem. Findings are traced to the code and verified, but the codebase says nothing about how the function is governed or who the business quietly depends on.
Level three exists because a deal usually needs both sides reconciled. Where the stated position and the observed system disagree, that gap is the finding, and it is reported with the evidence for each side rather than smoothed over.
What gets examined
The area lists below are the structure of the reports themselves. Levels three and four cover both lists.
Level one: areas assessed (13)
- Development strategy and methodology
- Information security
- Disaster recovery
- Business continuity
- Skills, qualifications and key-person risk
- Quality assurance
- Backups and archiving
- Infrastructure, hardware and environments
- Management and control
- Documentation
- System and software architecture
- DevOps processes: source control, requirements capture, testing
- Delivery and staging processes
Delivered as a written report: review summary, area-by-area findings and risks, additional issues identified, remediation and next steps, qualifications of the reviewer, conclusion.
Level two: areas examined (13)
- Platform classification and system comprehension
- Discovery and context-specific checks
- Architecture
- Code quality and maintainability
- Security
- Database and data model
- Hardcoded values and portability
- Testing
- Performance
- Dependencies and DevOps
- Production readiness
- Frontend
- AI-generated code
Includes intellectual property and licensing exposure, supplier dependencies, technical debt and key-person risk, each carried through to the remediation plan.
What the report actually looks like
Extracts from real reports, redacted. Nothing here identifies a client, a person or a repository.
Level oneThe review summary. Fifteen areas on one page, each rated for likelihood and seriousness and combined into a grade, with the rating scale defined in the report rather than left as a colour.Opens the full-size image in a new tab. 
Level oneOne area written up in full: what is in place, then the risks that follow from it. Black bars are redactions, not gaps in the original.Opens the full-size image in a new tab. 
Levels one to threeGrades are tied to an action, not left as an adjective. A means act now, B means a six month plan, C is budget dependent, D and E are monitored.Opens the full-size image in a new tab. 
Level twoThe code and platform audit opens with the score, the count, and the item to fix first, so a reader knows the position before reading a single finding.Opens the full-size image in a new tab. 
Level twoA single finding, traced to its source and written twice over: once for the investment decision, once for the engineer who has to fix it.Opens the full-size image in a new tab.
Every image above is from work actually delivered. Client names, people, environments and anything that could identify a business or a repository have been removed. Black bars are redactions applied for publication, not blanks in the report a client receives.
How code audit findings are verified
These four stages apply to code audit findings, at level two and above. An unverified finding is an opinion, and an opinion is not something you can put in front of an investment committee.
Stage 01
Findings validation
Every finding is checked back against the code and the configuration it came from, so nothing reaches you on the strength of a first impression.
Stage 02
Cross-reference verification
Findings are tested against each other. A symptom in one area is often a single cause in another, and that changes both the severity and the remediation cost.
Stage 03
Dynamic verification
Where access allows, behaviour is confirmed against the running system rather than inferred from the source alone.
Stage 04
Remediation validation
Each recommendation is tested for whether it is actually achievable by this team, on this estate, in the time the deal assumes.
Level one findings do not go through these stages, because there is nothing to verify them against. They are reported as stated by management and graded on that basis, never presented as verified.
Where something could not be assessed, it is marked as not assessed. That is more useful to you than a rating built on an assumption.
What you receive
All levels
Executive summary
Written in investment and board language, so it can go into a paper or an investment committee without translation.
From level one
Rated risk summary
A dashboard view of each area reviewed, rated for likelihood and seriousness and combined into a grade, with the rating scale explained in plain words.
From level two
Traced, verified findings
Each finding tied to the file, configuration or environment it came from, so it can be handed to an engineer or a warranty discussion without being restated.
From level three
Reconciliation of stated against observed
Where the management account and the system disagree, both are set out side by side, because the gap itself is usually the material finding.
From level four
Team and delivery observations
What the working cadence, ownership and key-person dependency look like in practice rather than on an organisation chart.
All levels
Material risks, with impact and severity
What each risk would cost, how likely it is, and when it becomes urgent, separated from the things that merely look untidy.
All levels
Strengths
What is genuinely good, because a report that only lists problems is not an assessment and does not help you price.
All levels
Questions requiring resolution
The specific questions to put to management or to warranty before completion, phrased so they cannot be answered with reassurance.
All levels
Remediation priorities in sequence
What to fix first, what it depends on, and what can safely wait until after the deal has closed.
Independence, stated plainly
I have no development team to sell you after the report lands, no referral fees from suppliers, and nothing to gain from where the remediation is placed. Plenty of technology diligence is carried out by firms who would also like to win the rebuild.
The reports are proprietary and confidential to the client who commissions them, which is why the examples on this page are described by structure rather than by name. If you need to see the shape of a report before instructing, I can walk you through a redacted one on a call.
Diligence experience on both sides of the table
I have raised growth capital at series A and B with private equity houses and private funds, and been the person answering the technical questions. That is a useful place to have stood before you are the one asking them: you learn quickly which answers are evidence and which are presentation.
“Tim is results driven with all his endeavours, focused on the delivery of on-time solutions to the benefit of the business, an assured change manager who incorporates business change and technology to maximum effect. Tim also excels at closing the communication gap between less technical senior managers and the hands-on development team.”
“Engaging Tim as an advisor was one of the best decisions we made for our company. Tim brings a wealth of experience, knowledge and a fresh perspective to the boardroom. He has helped us to make better strategic decisions, improved our governance and brought valuable connections to the table.”
Common questions
- What is technical due diligence?
- Technical due diligence is an independent assessment of a target company's technology carried out for an investor or acquirer. It tests whether the architecture, code, security, data, infrastructure, suppliers, technical debt and team can support the investment thesis, and what it will cost to put right anything that cannot.
- What are the levels of technical due diligence?
- There are four. Level one is a technology and operations review, graded at board level from what management and the documentation tell you. Level two is a code and platform audit, where every finding is traced back to the code, configuration or environment it came from. Level three runs both and reconciles them, so the management account is tested against the system rather than recorded. Level four adds on-site time with the team. Level three is the default for a transaction.
- What is the difference between a technology review and a code audit?
- The evidence base. A technology and operations review is built from interviews, documentation and what the company chooses to show, so it grades the development function but cannot independently validate it. A code and platform audit examines the codebase, configuration and environments directly, so each finding is traceable and verified. A review tells you what you have been told; an audit tells you what is there.
- Can technical due diligence be done without code access?
- Yes, at level one, and it is often the right first step before an offer. It should be read for what it is: an assessment of information the target provided. Nothing in it is independently validated, and anything that could not be checked is listed as not assessed rather than assumed. Where the software is material to the price, a code audit is needed on top.
- Does technical due diligence require an on-site visit?
- Not usually. Levels one to three are delivered remotely, which is how most UK, US and South East Asia deals run. An on-site level four is worth it when the people are as material as the platform: distributed teams, suspected key-person dependency, or a delivery record that does not match the plan. Travel is scoped and costed per engagement.
- How long does technical due diligence take?
- It is scoped to the transaction timetable rather than to a fixed package. The variables are the size of the estate, how much documentation exists, and how quickly the target's team can give access. Tell me the completion date you are working to and I will tell you honestly what can be evidenced by then.
- How much access do you need from the target?
- Read access to the source control, a conversation with the technical lead and whoever owns infrastructure, and sight of the environments. Where access is limited I say so in the report and mark what could not be assessed, rather than quietly filling the gap with an assumption.
- Are you independent of the suppliers you assess?
- Yes. I hold no development capacity to sell afterwards, take no supplier referral fees and earn nothing from the remediation being placed with anyone. The only thing the report has to serve is the decision you are making.
- Do you sign a non-disclosure agreement?
- Yes. Diligence reports are proprietary and confidential to the client commissioning them, and the reports themselves carry that restriction on every page.
- Can you help after completion?
- Often. The remediation plan is written to be handed to the target's own team, and where an investor wants someone accountable for it there is a fractional CTO or non-executive route into the business. That is a separate engagement, agreed after the report, never a condition of it.
- Do you only work on UK deals?
- Most diligence work is UK-based, and I take remote engagements with investors in the US and across South East Asia. On-site time outside the UK is agreed and costed per engagement.
Have a deal that needs the technology tested?
Send me the target, the thesis and the completion date. I will tell you which level of review fits and what can be evidenced in the time available.