Preparing your software for technical due diligence: a seller's checklist

Why sellers face a different test

If you plan to sell or raise investment in a software-dependent business within the next six to eighteen months, the most effective preparation is to assemble proof of ownership, licence compliance, security and scalability before a buyer’s reviewer finds gaps. I have built and sold businesses myself, so I have sat on the seller’s side of due diligence. As a development company we are the people who inherit, audit and fix codebases, and we offer a technical due diligence service. Most published checklists target buyers, but this one is written for the seller.

A buyer’s reviewer looks for risk to price into the deal. You, as seller, want to remove surprises that lead to price chips, warranties, indemnities or conditions precedent. KPMG describes technology due diligence findings being turned into purchase price adjustments, conditions precedent, warranties and indemnities, and warranty and indemnity insurance inputs. Paul Hastings notes that standard UK W&I insurance exclusions include matters fairly disclosed in the data room, so good disclosure starts with good preparation.

IP ownership and the written assignment gap

The first question a reviewer asks is whether you actually own the software. Under the Copyright, Designs and Patents Act 1988, employers own copyright in employees’ work made in the course of employment (s11(2)). For contractors, agencies or code written by founders before incorporation, the author retains ownership (s11(1)). Section 90(3) states an assignment is not effective unless in writing signed by or on behalf of the assignor.

A common gap is that the only proof of ownership is an email or a verbal understanding. In our own engagements, clients own 100% of the code and IP we write, with full source, documentation and infrastructure access handed over. If your history is messier, gather signed assignments now. Our FAQ on code ownership explains the principle in plain terms.

Open-source licence compliance and the AGPL trap

Almost every codebase uses open source. Black Duck’s 2026 Open Source Security and Risk Analysis (OSSRA) report analysed 947 commercial codebases from its own audits between November 2024 and October 2025, including 197 M&A transactions, so it is a sample of audited software rather than of all software. It found 98% contained open source, and the mean number of components per application rose from 911 to 1,180. More striking, 68% contained licence conflicts, up from 56% in the prior year, while 87% had at least one vulnerability and 78% had high-risk vulnerabilities.

Copyleft obligations catch sellers out. GNU AGPL v3 section 13 says that if you modify the program, users interacting with it remotely over a network must be offered the corresponding source. That matters for SaaS that is never distributed. Black Duck states that a GPL violation discovered during M&A due diligence can derail an acquisition, with remediation at that stage requiring significant refactoring. CISA describes a software bill of materials (SBOM) as a nested inventory of ingredients, and ISO/IEC 5230 (OpenChain) is the international standard for a compliance programme. Run a licence scan and produce an SBOM before the data room opens.

Security, infrastructure and AI-generated code

Reviewers will ask for a penetration test, a vulnerability backlog and an incident log. Where parts of the system were built with AI tools, they look harder at access control and secrets. We have audited AI-built (“vibe-coded”) apps several times and brought them into production. Recurring findings include exposed secrets and API keys in client-side code, databases with row-level security never configured, access control enforced only in the front end, and missing input validation.

If that sounds like your build, our vibe code rescue service can assess and harden it. Infrastructure should sit in the company’s name with documented access. The ICO fined Marriott £18.4 million in October 2020 over an attack on Starwood’s systems that began in 2014, before Marriott acquired Starwood in 2016, and went undetected until 2018. This shows inherited security debt can surface after close, so disclose and remediate early.

Architecture, technical debt and key-person risk

Documentation of architecture and scalability is often thin in founder-led businesses. A more dangerous gap is key-person dependency: the “only one developer understands it” problem. The Saeker project shows this risk clearly: the original developer had left and the legacy system had become almost impossible to maintain, so the directors invested in a replacement.

If your knowledge sits with one person, start transferring it now. A fractional CTO can document decisions, review architecture and reduce the risk that a buyer prices in a dependency premium. You should be able to show how the system scales under load without relying on tribal knowledge.

Third-party integrations and change-of-control

Most software businesses depend on other platforms: a CRM, an accounting package, a payment provider. A reviewer will look at the contracts and terms behind those integrations, particularly change-of-control clauses, termination terms and any usage tiers that would change under a new owner. Where an acquisition triggers a notification to a vendor, the buyer will want to know whether the integration continues unchanged. Mapping these dependencies early prevents a condition precedent appearing late in negotiations.

Data protection and disaster recovery

The ICO says that where a merger or acquisition transfers personal data to another controller, data sharing must be considered as part of due diligence, including what data is transferring, its original purposes and lawful basis. Produce a data map, confirm lawful bases and list processor contracts.

Disaster recovery is frequently claimed but rarely proven. Show backups and, importantly, evidence of tested restores. A reviewer will trust a documented restore test far more than a screenshot of a backup job.

Data room preparation table

The table below lists common documents, why a reviewer wants them, and a gap worth checking for before you hand each one over.

Document	Why the reviewer wants it	Gap to check for
IP assignment pack	Confirm chain of title for all code	Missing assignments from early contractors, agencies or founders’ pre-incorporation work
SBOM and licence scan	Identify copyleft and AGPL conflicts	Scan covers direct dependencies only, missing transitive components
Security audit report	Show pen test, backlog and incident history	Internal self-assessment presented as independent pen test
Architecture and scalability doc	Assess technical debt and growth path	No evidence of load testing or capacity limits
Backup restore evidence	Prove disaster recovery works	Screenshot of backup job, no recorded restore test
Data map and processor list	Support lawful basis review	Missing processor contracts for sub-processors

What to fix first

Prioritise in this order to spend the least and protect value:

1. Collect signed written assignments from every contractor, agency and founder for pre-incorporation work.
2. Run a licence scan, build an SBOM, and remove or replace any AGPL or unspecified copyleft components.
3. Audit AI-generated code for exposed secrets, missing row-level security and front-end-only access control, then harden it.
4. Document architecture and use a fractional CTO to break key-person dependency.
5. Map third-party platform contracts for change-of-control clauses and confirm continuity after the sale.
6. Perform and record a backup restore test.
7. Map personal data, lawful bases and processor contracts.

Each step is cheaper to complete months before the data room opens than to explain under deadline pressure.

This article is not legal advice; readers should confirm their position with their adviser.

Frequently Asked Questions

Who pays for remediation if due diligence finds issues after exclusivity?

KPMG describes findings becoming price adjustments or conditions precedent. A seller-side review from our technical due diligence service before exclusivity lets you fix gaps on your own terms, avoiding later negotiation over who funds remediation work identified late.

Can a fractional CTO help prepare for due diligence?

Yes. A fractional CTO can document architecture, review scalability and break key-person dependency before buyers arrive. The “only one developer understands it” problem is exactly what a buyer will price in. Engaging this resource months ahead lets you produce the architecture and scalability docs reviewers expect, rather than relying on tribal knowledge during the data room stage.

If you would like a seller-side review of your codebase before buyers begin their own work, our technical due diligence service can start the process. You can also reach us directly at our contact page to discuss timing and scope.