Technical Due Diligence: Auditing the Code Before You Buy or Invest in a Software Company

Technical due diligence before buying or investing in a software company: IP chain of title, open source, security, architecture, team risk and deal terms.

Key Takeaways

  • Technical due diligence answers one question for a buyer or investor: does the software do what the seller says, can it grow with the business plan, and what will it cost to fix what it can't?
  • The findings that move deals are rarely about code style. They are IP ownership gaps, open-source licence problems, security incidents, key-person dependency and technical debt that blocks the roadmap.
  • In France and the EU, code written by freelancers or agencies belongs to its author unless rights were assigned in writing. A seller who can't show those assignments may not own what it's selling.
  • A good report doesn't just list problems. It prices them: what to fix before closing, what to fix in the first year, and what belongs in the purchase agreement.
  • Findings usually become price adjustments, conditions precedent, specific warranties and indemnities, escrow or retention plans, not a reason to walk away.

Technical due diligence is an independent review of a software company's product, code, infrastructure and engineering team, carried out before an acquisition or an investment. Financial and legal due diligence check the numbers and the contracts; technical due diligence checks the asset that usually justifies the price. This guide is for acquirers, investors and boards. It covers what a review should look at, what to ask the seller for, and how findings translate into deal terms. It is a practical guide, not legal advice: your lawyers decide how findings are reflected in the documents.

When you need one

  • Acquiring a software company, or a business whose value depends on its software.
  • Investing in a startup or scale-up where the product is the main asset.
  • Buying a product or codebase outside a share deal (an asset purchase).
  • Before a merger where two platforms will be combined.
  • As a seller, to find and fix problems before a buyer's team does. A vendor due diligence often shortens the process and protects the price.

What a technical due diligence covers

1. Intellectual property: does the seller own the code?

This is the area most likely to produce a serious finding, and the one most often skipped by reviews that only read code.

  • Chain of title. Who wrote the code? Employees' work belongs to the employer by default under French and EU law, but work by freelancers, agencies and founders before incorporation belongs to its author unless rights were assigned in writing. Ask for the contracts. Our guide on who owns the code explains why paying for code doesn't transfer ownership on its own.
  • Third-party and pre-existing components. Code licensed from a previous agency, a former employer or a partner, with or without a written licence.
  • Open-source licences. An inventory of dependencies and their licences, and a check for copyleft licences (such as GPL or AGPL) used in ways that could oblige the company to publish its own source. A software bill of materials (SBOM) makes this reviewable; formats such as SPDX and the OpenChain standard (ISO/IEC 5230) describe how mature companies manage it. In France, the APP offers an IP audit that includes source code scanning for undeclared open-source components.
  • Where the code and accounts live. Repositories, domains, cloud accounts and app store accounts should belong to the company, not to a founder or a former contractor.

2. Architecture and scalability

  • Does the architecture support the business plan: ten times the users, new markets, new products, a mobile app?
  • Where are the bottlenecks: database design, a single server, synchronous integrations, a monolith that can't be deployed in parts?
  • Is the technology mainstream and supported, or a niche stack that will be hard to hire for?
  • What would it take to integrate with the acquirer's systems?

3. Code quality and technical debt

Not "is the code pretty", but "what does it cost the business?"

  • Test coverage on the business rules that matter.
  • How long it takes to ship a change, and how often releases break things.
  • Areas everyone is afraid to touch, and why.
  • An estimate of the effort to fix what blocks the roadmap, so debt becomes a number in the model rather than a vague worry.

4. Security and data protection

  • Past incidents and how they were handled. Ask directly, and check whether customers or authorities were notified where required.
  • Current exposure: authentication, authorization, secrets management, dependency vulnerabilities, logging. A review against a recognised baseline such as OWASP ASVS keeps it objective.
  • Personal data: what is stored, where, on what legal basis, with which processors, and whether the security measures GDPR article 32 expects are in place.
  • Penetration tests: when, by whom, and whether findings were fixed.

5. Infrastructure, operations and cost

  • Hosting setup, backups that have actually been restored, monitoring, incident history and uptime.
  • Cloud cost and how it scales with customers. A margin that looks healthy at today's volume can disappear at the volume in the business plan.
  • Vendor lock-in to services that would be expensive to leave.

6. Team and process

  • Key-person risk. How much of the system lives only in one or two heads? What happens if the CTO or a founding engineer leaves after closing?
  • Contractors and subcontractors doing core work, and on what terms. See our guide on spotting junior teams and hidden subcontractors.
  • Documentation, onboarding, code review and deployment practices.

What to ask the seller for

A short, early data request saves days:

  1. Access to repositories (read-only), with history.
  2. Architecture documentation and an infrastructure overview.
  3. The list of everyone who has contributed code, with their status (employee, freelancer, agency) and the relevant IP clauses.
  4. The dependency list or SBOM, and any open-source policy.
  5. Security documentation: penetration test reports, incident log, data processing register.
  6. Hosting invoices for the last twelve months.
  7. The product roadmap, so the review can test feasibility against it.
  8. Time with the technical leads, without the sales team.

How findings shape the deal

FindingTypical response
Missing IP assignments from contractorsCondition precedent: signed assignments before closing; specific warranty
Copyleft licence used in a way that creates riskRemediation before closing, or a price adjustment and indemnity
Unpatched critical vulnerabilitiesFix before closing, or a funded remediation plan
Past incident not disclosedSpecific indemnity; reassess trust in other disclosures
Key-person dependencyRetention and incentive plans; knowledge transfer obligations
Heavy technical debt blocking the roadmapPrice adjustment reflecting the remediation cost; revised plan
Code or accounts held by a founder personallyTransfer to the company as a closing condition

In French share deals, many of these end up in the garantie d'actif et de passif (the seller's warranty and indemnity package); for licensed components the company can't own, source code escrow is another tool. Your lawyers will choose the mechanism. The technical team's job is to make each risk clear and give it a cost.

How long it takes

It depends on the size of the product and the pace of the deal. A focused review of a single product can be done in a couple of weeks; a short exclusivity period sometimes compresses that to days, at the price of depth. Agree the scope early: IP and security are rarely the parts to cut.

Frequently asked questions

What's the difference between technical due diligence and a technical audit? A technical audit helps an owner improve its own system. Technical due diligence serves a buyer or investor making a decision, so it weighs IP, team and cost risk alongside the code, and it ends in deal recommendations rather than a backlog.

Will the seller let us read the code? Usually, under a confidentiality agreement and often in a controlled environment. If a seller refuses any technical access, that is itself a finding.

Should the seller commission its own review first? Often yes. A vendor due diligence finds problems while there is still time to fix them, and a clean report supports the price.

Can you review a codebase in a technology you don't use day to day? The IP, security, infrastructure and team parts are largely stack-independent. For the code itself, ask any reviewer which stacks they know well and where they would bring in a specialist.

FNB Solutions carries out technical audits and due diligence for buyers, investors and sellers of web software. See our technical audit service or get in touch to scope a review.

Sources

All insights →