Technical due diligence for software: when you need it, what it checks (architecture, code, security, IP, open source, team), standards and red flags.
Short answer. Technical due diligence is an independent review of a software product and the team behind it, done before an investment, an acquisition or a change of supplier. It checks architecture, code quality, security, scalability and infrastructure, IP ownership and open-source licences, the team and delivery process, and estimates the cost of fixing what it finds. Reviewers commonly use OWASP ASVS for security, the ISO/IEC 25010 quality model and the UK Software Security Code of Practice. The output that matters is a list of risks with a cost and a priority, not a score.
This guide is for investors, acquirers, founders preparing to raise, and companies taking over a product from another team. It sets out what a review covers, the process, the standards, the red flags and what happens next.
Last checked: 2 November 2026.
When you need technical due diligence
- Investing in or buying a software business, to check that the product is what the pitch says and to price the risks.
- Preparing to raise, so you find and fix problems before an investor's reviewer does.
- Taking over a product from another agency, freelancer or in-house team that is leaving.
- Scaling a product built quickly, including apps built with AI coding tools; see taking an AI-built app to production.
- Deciding whether to rebuild, before committing to the most expensive option. See legacy system modernisation.
What a review covers
| Area | Questions it answers |
|---|---|
| Product and architecture | Does the architecture fit the product and its growth plans? Where are the single points of failure? |
| Code quality | Is the code readable, tested and consistent? How much is duplicated or dead? How hard is it to change? |
| Security | Authentication, access control, secrets handling, dependency vulnerabilities, data protection, results of any penetration tests |
| Infrastructure and operations | Hosting, environments, CI/CD, monitoring, backups that have been restored, incident history |
| Scalability and performance | What breaks at ten times the current load, and what it would cost to fix |
| IP and licences | Who owns the code, whether assignments are signed, which open-source licences are used and whether obligations are met |
| Data | Where personal data is stored, who can access it, data processing agreements, transfers outside the UK |
| Team and process | Key-person dependency, documentation, how work is planned, tested and released |
| Costs | Hosting and third-party service costs now and at scale, including AI model usage |
Standards reviewers use
| Standard | What it is used for |
|---|---|
| OWASP Application Security Verification Standard (ASVS) 5.0 | A detailed list of security requirements to check an application against; version 5.0 was released in May 2025 |
| ISO/IEC 25010 | A product quality model covering characteristics such as functional suitability, performance efficiency, compatibility, reliability, security and maintainability |
| UK Software Security Code of Practice | A voluntary code from DSIT and the NCSC for software suppliers, first published in May 2025; also referenced by NHS DTAC |
| Open-source licence terms | The licences themselves, for example the GPL and AGPL, to check obligations on distribution and network use |
There is no single mandatory standard for technical due diligence in the UK; reviewers combine these with their own checklists.
How a review works
- Scope and access. Agree the questions, then get read access to the repository, infrastructure and documentation, under NDA.
- Interviews with the technical lead and the people who run the product.
- Automated analysis of code, dependencies and licences, plus manual review of the critical paths.
- Security and infrastructure review, including how secrets, backups and access are handled.
- Findings and costs: each risk with its impact, the fix, an effort estimate and a priority.
- Read-out to the investor, buyer or board, with a plan for the first 90 days.
Red flags we see most often
- Code or hosting accounts owned by a former supplier or a single individual, with no signed IP assignment.
- No automated tests and releases done by hand from one person's laptop.
- Secrets such as API keys committed to the repository.
- Outdated frameworks and dependencies with known vulnerabilities.
- Backups that have never been restored.
- Copyleft components used in ways that may oblige sharing source code.
- Personal data copied into test environments or accessed from abroad without safeguards.
- AI features without evaluation, cost limits or logging.
Pick the features you need in our calculator and get a ballpark price in a couple of minutes.
After the review: keep, fix or rebuild
A rebuild is rarely the first answer. Most products need a short hardening phase: ownership and access sorted, secrets rotated, tests on the critical paths, dependencies updated, monitoring switched on. Only then is it clear whether parts need rebuilding. For scale, at Magora's published day rate 10 developer-days is about £3,900 and a full developer-month about £7,800; a fixed price for a larger programme comes after Discovery.
If the product changes hands, also check the contract basics in software development contracts: IP, escrow and payment terms.
Taking over or investing in a product? Send us a short description and we will scope a code and architecture review, tell you plainly what can be kept, and fix what blocks launch or growth first. More about legacy system modernisation.
Frequently asked questions
What is technical due diligence for software?
An independent review of a software product and the team behind it, usually before an investment, acquisition or change of supplier. It covers architecture, code quality, security, scalability, infrastructure, IP and open-source licences, the team and delivery process, and the cost of fixing what is found.
When do you need technical due diligence?
Before investing in or acquiring a software business, before taking over a product from another agency or freelancer, before scaling a product built quickly (including AI-built apps), and before a major rebuild decision.
How long does technical due diligence take?
It depends on the size of the product and access to code and people. A focused review of a small product can take days; a full review of a larger platform takes weeks.
What standards are used in technical due diligence?
There is no single mandatory UK standard. Reviewers commonly use the OWASP Application Security Verification Standard for security, the ISO/IEC 25010 quality model for code and product quality, and the UK Software Security Code of Practice for supplier security practices.
Does technical due diligence check open-source licences?
It should. Copyleft licences such as the GPL and AGPL can require sharing source code in some circumstances, which matters to investors and buyers.
Can Magora review a product built by another team?
Yes. We start with a code and architecture review, say plainly what can be kept, and fix what blocks launch or growth first. The price depends on what is in the product, so we scope it before quoting.
Sources
- OWASP Application Security Verification Standard
- GOV.UK: Software Security Code of Practice
- NCSC: Software Security Code of Practice
- GNU: frequently asked questions about the GPL
- CDPA 1988, s90 (assignment must be in writing)
Pavel Shevtsov
Pavel Shevtsov is a seasoned professional in the field of software development, currently serving as the Managing Director at Magora, a leading software development company known for its innovative solutions. With a passion for leveraging technology to solve complex business challenges, Pavel has played a pivotal role in Magora's growth and success.
LinkedIn