Technical due diligence: what investors check and how to prepare

In technical due diligence, an investor or buyer's reviewers check whether your product works as described, whether it can grow, whether it is secure, whether you own what you say you own, and whether the business depends on a few people. Founders prepare by gathering documents, cleaning up access and ownership, and fixing the cheap problems first.

Why do investors review technology?

Money is going in on the basis of a claim: this product does what we say, and it will keep doing it as we grow. Due diligence tests the claim. For a software business the technology is a large part of the asset, so the investor wants to know its condition, its risks and what it will cost to carry the plan forward.

A review does not look for perfection. Young products have shortcuts. What matters is that you know where they are, can explain them and have a plan.

What do reviewers look at?

Product and architecture: how the system is built, what it depends on and how the parts connect. Does the design suit the plan? Can it handle ten times the users? Are there obvious bottlenecks?

Code quality: is the code readable and consistent? Are there automated tests? Is there a review process? Is the repository tidy? Reviewers often sample the code and look at history to see how the team works.

Infrastructure and operations: where it runs, how it is deployed, how it is monitored, how it recovers. Are there backups that have been tested? Is the cloud bill understood? See backups for a small business.

Security: access control, MFA, secrets handling, patching, past incidents, penetration test results. For a product handling customer data, a VAPT report is useful evidence.

Data and privacy: what personal data is held, where, and under what consent. For Indian companies, how it aligns with the Digital Personal Data Protection Act, 2023. A clear data map and notice practice reassure reviewers. See the first DPDP steps. This is not legal advice; counsel advises on legal questions.

Intellectual property: who wrote the code? Do contractors and former staff have signed agreements assigning ownership to the company? What open-source licences does the product use, and do any, such as the GPL or AGPL, create obligations? Which third-party software is the product built on?

Team and key-person risk: who knows how things work? What would happen if the lead developer left tomorrow? Is knowledge written down?

Technology spending and vendors: what is paid for, to whom, and whether contracts allow a change of control. Dependence on a single vendor or agency is a point of concern.

Roadmap and delivery: how work is planned and delivered, how fast the team ships, and how realistic the roadmap is against the people available.

What tends to raise concern?

• Code or accounts held by a freelancer or agency with no assignment in writing.
• Everything running under one person's personal login.
• No backups, or backups never tested.
• Secrets committed in the code repository.
• No tests, no staging environment, and releases done by hand on production.
• A core feature built on an unsupported or abandoned library.
• Personal data collected with no clear purpose or notice.
• A system that depends on one person's memory.
• Claims in the pitch, such as AI features, that the product does not actually deliver.

None of these is fatal alone. Each one changes the conversation about price, terms and timing.

How should a founder prepare?

Start two or three months before the process if you can. A practical list:

1. Put ownership in order: domains, cloud accounts, app store accounts and repositories in the company's name. Contractor and employee agreements covering IP assignment.
2. Make a system map: one page showing the main parts, where data lives, and which vendors are involved.
3. List your dependencies: open-source libraries and their licences, paid services, third-party APIs.
4. Collect evidence: test results, the last security test, backup restore records, uptime history, incident notes.
5. Fix quick wins: rotate exposed secrets, turn on MFA, remove ex-staff access, set up backups, update packages.
6. Write short documents: architecture overview, deployment steps, runbook for common failures. Even rough notes help.
7. Prepare honest answers: know your weak points and what you plan to do about them. Reviewers trust founders who name problems first.
8. Set up a data room: one organised, access-controlled place for documents and read-only repository access.

What does the output look like?

Most reviews end in a written report: a summary for the investor, findings rated by severity (often red, amber and green), and recommended actions with estimated effort. The investor uses it to decide on the deal and how to structure it. The founder can use it as a work plan for the first year after.

What are the trade-offs?

Preparing takes time away from building and selling. A cleanup sprint before a raise delays features. But a messy surprise in the middle of a deal costs more.

Over-polishing is a trap. You are not trying to make the product perfect. You are trying to make it understood, owned and safe enough for the stage you are at.

Independence matters if you commission a pre-review. The reviewer should have no stake in selling you fixes. They should tell you what an investor would see.

Where does TechSum fit?

We run technical due diligence for investors and acquirers, and pre-diligence reviews for founders who want to find problems before others do. See the technical due diligence page and the Tech Consultancy pillar. A Tech Second Opinion is a smaller first step on one build, and the free health check gives a quick view of your public-facing setup.