Technical Due Diligence for Software: Checklist & Costs

Technical due diligence is an independent review of a software product’s code, architecture, security, licences and team, carried out before a sale, investment or acquisition. Its job is to show what the technology can really support. Our review is fixed scope and starts from £4,000. It reviews your codebase and architecture, ranks the risks with a practical fix for each, and ends in a written report any team can act on.

This article explains what a software audit checks and gives a technical due diligence checklist you can run on your own product. It also lists the red flags that tend to change a deal and says what a good report contains. It covers the technical workstream only. We are not M&A, legal or financial advisers, so valuation, contracts and tax sit with the right professionals alongside it. If you want us to run the review, our technical due diligence service has the scope and price.

Key takeaways

• Technical due diligence reviews architecture, code quality, security, dependencies and licences, who owns the code, data handling, team and process, and technical debt.
• Running the review before a buyer or investor does gives you time to fix findings rather than explain them.
• Code ownership and open-source licences usually need a lawyer. The audit produces the evidence and the lawyer interprets it.
• Our technical due diligence is a fixed-scope review from £4,000. A product built mainly with AI tools can start with a £3,000 rescue audit instead.

What is technical due diligence for software?

Technical due diligence is a structured check on whether a software product is what its owners say it is. It answers a few plain questions about reliability, room to grow, security, ownership and whether the people behind it can keep it going.

Three kinds of reader commission it. An investor wants to know the technology can support the plan behind a funding round. An acquirer buying a software business wants to know what they are inheriting. A seller runs it first, so that the first reader of the findings is someone who can still fix them.

It sits alongside the financial and legal reviews in a deal and does not replace them. A technical review can tell a lawyer which open-source licences are in the product and which contractors wrote the code. It cannot tell you whether your contracts say what you need them to say, and a good reviewer states that limit in the report.

A code audit and technical due diligence overlap but are not the same thing. A source code audit looks at the code. Due diligence is wider, because it also looks at ownership, process, the team and the infrastructure the code runs on.

What does a software code audit check?

A thorough review covers eight areas. The table shows the question each one answers, and the sections after it add detail where public sources exist.

Area	The question it answers
Architecture and scalability	What breaks first as use grows?
Code quality	Can a new engineer change it safely?
Security	Could someone get in or get data out?
Dependencies	What third-party code is inside?
IP and licences	Does the company own it, and can it sell it?
Data protection	Is personal data handled properly?
Team and process	Who knows how it works?
Technical debt	What will fixing it cost?

Architecture, code quality and team. The reviewer reads the structure and the infrastructure and asks what a failure would cost. Tests, deployment and readability decide how safely a new engineer can change things. The reviewer also asks who understands each part, whether it is written down, and whether one person holds the only set of credentials.

Security

Security review starts with access control, authentication, how secrets are stored and whether known-vulnerable components are in use. The OWASP Top 10:2025 is the usual shared vocabulary. OWASP describes it as an awareness document for developers and web application security. Its first category is Broken Access Control and its third is Software Supply Chain Failures.

The UK government’s Software Security Code of Practice, updated in January 2026, sets out principles for software suppliers. They include managing third-party components and running a vulnerability disclosure process. The NCSC calls Cyber Essentials the minimum standard of cyber security the Government recommends for organisations of all sizes. It rests on five controls, one of which is security update management.

Dependencies and open-source licences

Software usually relies on third-party components, so the audit builds an inventory of them. It records each component, its version and its licence. SPDX is an open standard for that information and is published as ISO/IEC 5962:2021.

The licence matters because the terms differ. The Open Source Initiative lists licences that have passed its review process. Some are “copyleft”, which the GNU project describes as the rule that when you redistribute a program you cannot add restrictions that deny other people the central freedoms. Whether a given licence conflicts with how your product is sold or distributed is a legal question. The audit gives your lawyer a complete list to interpret.

Who owns the code

Under the Copyright, Designs and Patents Act 1988, the author of a work is the first owner of the copyright. Where an employee makes the work in the course of employment, the employer is the first owner, subject to any agreement to the contrary.

Code written by someone who is not your employee therefore starts out owned by someone else. A freelancer is usually the first owner of what they write, and an agency is usually the first owner of what its own employees write. Moving ownership to the company needs a written assignment signed by or on behalf of the person assigning. A reviewer will ask to see the paperwork behind every outside contributor. This is a summary of the statute and not legal advice.

Data protection

If the product holds personal data, the review checks how it is protected. The ICO’s guide to data security says the UK GDPR expects personal data to be processed securely using “appropriate technical and organisational measures”. It also says the law does not define which measures. It points to a process for regularly testing, assessing and evaluating whether the measures work. The ICO notes this guide is under review after the Data (Use and Access) Act.

The stakes are real. The ICO’s fining guidance sets the higher maximum fine at £17.5 million or, for an undertaking, 4% of total worldwide annual turnover in the preceding financial year if that is higher. In practice a reviewer asks who can reach the data, where it is stored, whether access is logged and whether anyone has tested the controls.

Technical due diligence checklist for founders

Run this list before anyone else reads your code. Answer each question honestly. Anything you cannot answer within a minute is a finding.

1. Access. Can you list everyone with access to the code, hosting accounts and admin tools, and has access been removed for people who left?
2. Ownership. Do you hold a signed assignment from every contractor, freelancer and agency who wrote part of the product?
3. Dependencies. Do you have a list of third-party components with their versions and licences?
4. Unsupported software. Is anything running on software that no longer receives security updates?
5. Secrets. Are passwords, API keys and tokens kept out of the code and out of shared documents?
6. Access control. Can one customer ever see another customer’s data, and has anyone tried to make that happen?
7. Tests and deployment. Can you release a change without one person doing it by hand, and can you roll it back?
8. Backups. Do you have backups, and have you restored from one recently?
9. Personal data. Do you know what personal data you hold, where it sits and who can reach it?
10. Documentation. Could a competent engineer you have never met understand how the system works from what is written down?
11. People. If your lead engineer left tomorrow, what would stop working?
12. Known problems. Do you keep a list of known issues, with a rough idea of what each would cost to fix?

Every “not sure” is a question a reviewer will ask. If the product was built mainly with an AI coding tool or a no-code platform, questions 5, 6 and 7 deserve extra attention. The next two sections cover what the common answers mean.

Red flags a technical review turns up

These are the findings we would expect to matter most to a buyer or investor, with the first fix for each. Each one is easier to deal with before it appears in someone else’s report.

Red flag	Why it matters	First fix
One person knows everything	The product stops if they leave	Document it, share access
Contractor code, no assignment	Ownership is unclear	Get signed assignments
Unsupported components	Known weaknesses stay open	Update or replace
Unchecked licences	Terms may clash with your model	Build an inventory, ask a lawyer
No tests, manual releases	Every change carries risk	Cover the critical paths
Secrets in code, shared logins	Anyone with access gets in	Rotate and move them
AI-built app, thin auth	The demo hides the gaps	Audit, then harden or rebuild
Personal data, no owner	Data protection exposure	Map the data, name owners

The AI-built row deserves a word. Tools such as Lovable, Bolt, Cursor and Replit can produce a working app quickly. The areas to check first in one are authentication, security, tests and the data model, which is why we start those engagements with a fixed audit rather than a guess.

How to fix red flags before diligence starts

The right first step depends on what the checklist showed.

• The system has outgrown its design. Our rebuild discovery is a £4,000 fixed-price assessment of one system. It reverse-engineers what the system does, then gives a straight rebuild-or-refactor recommendation and a costed plan. It will say “don’t rebuild” where that is the honest answer. Our guide to legacy systems covers the same decision in more depth.
• The product was built with AI tools. Vibe code rescue starts with a £3,000, one-week codebase assessment covering security, authentication, the data model, architecture and test coverage. It ends with a go, save or rebuild verdict. A rescue build, from £8,000, hardens what is salvageable and rebuilds the risky parts.
• Nobody senior can answer technical questions. A fractional CTO gives you technical leadership without a full-time hire. Advisory engagements start from £3,000 a month. Our explainer on what a fractional CTO is covers when it makes sense.
• You need a costed plan as well as a review. Our architecture and roadmap work, from £8,000, takes a review through to a delivery plan.

None of these is mandatory before a technical review. Many findings can simply be disclosed with a plan attached. The point is to decide that deliberately.

What technical due diligence costs

Our technical due diligence is a fixed-scope review from £4,000, with the price agreed before work starts. Scope and price are fixed upfront, and payment follows milestones as each stage is delivered. If a build follows, you can cancel it within the first 21 days for a full refund.

Option	Use it when	Price
Technical due diligence	You want your code reviewed	From £4,000
Architecture and roadmap	You also want a delivery plan	From £8,000
Rebuild discovery	One system may need replacing	£4,000
Rescue audit	The app was built with AI tools	£3,000

What drives the effort is the size of the codebase, the number of systems around it and how much infrastructure is in scope. A single web application maintained by a small team is a smaller review than a platform with several integrations.

We do not quote market rates for other providers, because we have not found an independent, published benchmark we can verify. A large transaction may call for a bigger advisory team than ours. Our fixed-scope review covers your own codebase and architecture, with the risks ranked and a practical fix for each. For wider context on what software costs to build, see our guide to software development cost in the UK.

What a technical due diligence report should contain

A report is useful if the people who read it can act on it. Ours is written so that any competent team can use it, whether or not they work with us. A list of everything wrong helps nobody decide, so the report ranks what it finds.

Look for these parts in any report:

• A plain-English summary. The verdict and the findings that matter most come first.
• Ranked findings. Each is rated by likelihood and cost, with a practical fix.
• Evidence. Each finding points to where it was seen, so your team can verify it.
• Inputs for your lawyer. The dependency and licence inventory, and a record of who wrote what.
• Scope and limits. What was reviewed, what was not, and what needs a specialist.

Your next step

If a raise or sale is coming, the practical first move is a scoped review of your own product. Our technical due diligence starts from £4,000. We agree the scope and price with you first, and you receive a written report any team can act on.

If you are not sure the product is ready for that, run the checklist above this week. Whatever you cannot answer is where the review would start.