Technical due diligence: how to prepare your tech for investors

Key points

• Due diligence asks whether the company can rely on its technology. A code audit asks how good the code is. The first includes the second, and much more.
• Ownership questions sink deals more often than code quality: missing IP assignments, copyleft code in the wrong place, accounts in a former contractor’s name.
• Keep a list of open-source components and their licenses, ideally as an SBOM in a standard format such as SPDX.
• Show security as habits with evidence: access reviews, dependency updates, tested backups, and how you handled past incidents.
• Bus factor matters. If one person holds the knowledge or the passwords, that is a risk the buyer will price in.
• Disclose known problems with a plan. A surprise found by the other side costs more trust than a weakness you named first.

What technical due diligence is, and who runs it

Before an investor puts money in or a buyer acquires the company, they check that what they are buying is what they were told. Technical due diligence is the part of that check that covers the product and the way it is built and run. The work is often done by the buyer’s own engineers, an advisor, or a firm hired for the purpose, and it usually mixes a questionnaire, document requests, interviews with your team and read access to some systems.

Depth varies with the deal. An early investor may only want a call with the technical founder and a look at the architecture. An acquirer buying the product itself will want the code, the licenses, the security history and the people. Either way, the questions fall into the same areas.

How it differs from a code audit

A code audit you commission first is one of the best ways to prepare: you see the findings before the other side does, and you can fix or explain them on your own terms.

What investors and buyers look at

IP and open-source licenses

Ownership is where small companies most often get surprised. Paying a freelancer or agency does not by itself transfer the copyright in many countries; a signed assignment does. Who owns the code covers the rules in the US, the UK and India, and how to fix a missing assignment.

Open source is the other half. Almost every product uses it, which is fine, but the buyer will want to know which licenses are in the product and whether any of them conflict with how you sell it.

• The Open Source Initiative approves licenses that meet its Open Source Definition. A license outside that list, or a component with no license at all, needs a closer look.
• Permissive licenses, such as MIT and Apache 2.0, mostly ask you to keep notices. Copyleft licenses, such as the GPL, can require you to release your own source code when you distribute software built on them.
• The AGPL reaches network services: if you modify AGPL code and users interact with it over a network, the license says you must offer them its source. For a web app or API, that is the license to check first.
• An SBOM, a software bill of materials, is the standard way to hand this over. CISA describes it as a nested inventory, a list of ingredients that make up software components.
• SPDX, an open standard published as ISO/IEC 5962:2021, gives a common format for SBOMs and short identifiers for licenses, so both sides read the same list the same way.

Security and data protection

Nobody expects a startup to be perfect. Reviewers want to see that the common risks are handled and that someone owns security. The OWASP Top 10, which OWASP calls a standard awareness document, is the usual reference: its 2025 edition puts broken access control first and software supply chain failures third. For a deeper check, OWASP’s Application Security Verification Standard, version 5.0.0, gives a list of requirements a tester can verify. Our web app security checklist turns these into practical steps.

Personal data carries its own questions, and the answers depend on where you and your users are. Two examples, and a note on the rest:

• United Kingdom: the ICO’s data sharing code says sharing data in a merger or acquisition should be part of due diligence. The buyer should establish what data is moving, the purposes it was first collected for, the lawful basis for sharing it, and whether those purposes change, and consider how to tell the people concerned.
• European Union: under the GDPR, the European Commission lists obligations such as informing individuals, keeping data secure, notifying data breaches and, in some cases, appointing a data protection officer. A buyer will ask how you meet each one.
• Elsewhere, such as the US states with privacy laws or India, the rules differ, but the questions a buyer asks are much the same: what you hold, why, on what basis, and what went wrong before.

This is general information, not legal advice. Ask a lawyer in your country, or your data protection regulator’s guidance, about your own case.

A preparation checklist

1. Make a list of every account the product depends on: code hosting, cloud, domains, app stores, email, analytics, payment providers and AI services. Move any that are in a person’s or contractor’s name into the company’s, with at least two admins.
2. Collect a signed IP assignment from every founder, employee and contractor who wrote code or designs. Fill the gaps now.
3. Generate an SBOM or license report from your dependencies and review any copyleft or unknown licenses.
4. Write a short architecture overview with a diagram, the main data flows and the reasons behind the big choices.
5. Check that a new engineer could build, test and deploy from the repository and its README alone.
6. Gather security evidence: who has access to what, how secrets are stored, when backups were last restored, and any test reports or incidents.
7. Write a data map: what personal data you hold, where it lives, which processors touch it and how long you keep it.
8. Write down known problems, from technical debt to scaling limits, with what you plan to do about each.
9. Prepare people: who will answer which questions, and who else on the team can explain each part of the system.

Common red flags

• Code, cloud or app store accounts held by a former contractor or a single founder’s personal login.
• No signed IP assignment from someone who wrote a large part of the product.
• AGPL or GPL code inside a product whose business model depends on keeping the source closed, with nobody aware of it.
• Secrets in the repository, shared passwords, and former staff who still have access.
• No tests, no repeatable deploy, and one person who is the only one able to release.
• Personal data with no clear purpose, no retention rule, or a past breach that was not handled as the law required.
• Claims in the pitch deck that the product cannot back up, such as features that are still manual behind the scenes or AI that is mostly rules.
• A rewrite planned but not scoped. If the codebase needs one, Rewrite vs refactor helps you decide and explain it.

Most of these can be fixed before a deal, and the rest can be disclosed with a plan. When BYD Tech builds or takes over a product, the code lives in the client’s GitHub from day one, IP is assigned to the client, and AI-assisted work is reviewed by an engineer, which keeps the ownership and history questions simple. Web app development describes how we work.