Technical due diligence is the part of a fundraise where an investor, or an expert they hire, looks under the bonnet of your product. At seed stage it may be one long conversation with a technical partner. Later rounds can involve a written questionnaire, access to your code and a report that goes to the investment committee. Weak answers can slow a round down and invite tougher terms just when you need momentum. This guide explains what reviewers usually look at and how to prepare well before the request arrives.
What technical due diligence tries to answer
Reviewers care less about elegant code than about four questions:
- Does the product work as described, and can it support the growth in the business plan?
- Does the company own what it has built?
- Are there hidden risks, such as security gaps, legal exposure or a single person holding all the knowledge?
- Can this team keep building at the pace the plan assumes?
The areas reviewers check
Architecture and scalability
Expect questions about how the system is put together, where it is hosted and what happens if usage grows tenfold. A simple diagram and a short written explanation go a long way. Reviewers are wary of both extremes: a fragile prototype that needs rebuilding before growth, and an over-engineered system that a small team cannot maintain.
Code quality and engineering habits
Reviewers may read parts of the codebase or run automated scanners. They look for consistent structure, automated tests on the important paths, code review on every change and a repeatable deployment process. Some messiness is normal in a young company. A team that knows where its technical debt sits and has a plan to pay it down looks far better than one claiming there is none.
Intellectual property ownership
This is where serious problems hide. Reviewers check that every founder, employee and contractor who wrote code has signed an agreement assigning intellectual property to the company. Code written by a founder before incorporation, or by a freelancer with no written contract, can leave ownership unclear. They also check open-source licences. Most are permissive, but some copyleft licences place conditions on how you distribute software that includes them. The Open Source Initiative’s licence list is a useful reference, and a lawyer should confirm how any copyleft code affects you.
Security
Expect questions on access control, encryption, how secrets such as API keys are stored, backups, logging and past incidents. In India, CERT-In’s 2022 directions require many organisations to report certain cyber incidents within six hours of noticing them, so reviewers may ask whether you know your obligations. Larger investors may ask for a recent penetration test.
Data protection
If you handle personal data, reviewers want to see that you know what you collect, why, where it is stored and who can access it. India’s Digital Personal Data Protection Act 2023 and its 2025 Rules are being phased in, with most obligations due to apply from May 2027, so a credible plan matters even before the deadline. Selling to the UAE, the EU or elsewhere brings its own rules.
Team and key-person risk
Who can deploy to production? Who knows how billing works? If the honest answer to several questions is one person, that is a risk the investor will price in. They will also look at hiring plans and whether the technical leadership fits the next stage.
Third parties and costs
Reviewers look at which external services you depend on, what happens if one fails or raises prices, and how your hosting costs grow with users. A reasonable cost-per-customer figure for infrastructure is a strong answer.
A preparation checklist
Start three to six months before you plan to raise. Most of this is useful even if you never raise.
- Collect signed IP assignment agreements from every founder, employee and contractor. Fix gaps now, while people are reachable.
- Move all code, cloud, domain and app store accounts into company ownership, with at least two admins.
- Write a two-page architecture overview with a diagram.
- Generate a list of open-source dependencies and their licences. Many package managers and scanning tools can do this automatically.
- Write down your known technical debt and the plan to address it.
- Document security basics: who has access to what, two-factor login, backups tested by restoring them, incident response contacts.
- Map the personal data you hold: what, why, where, who can see it, how long you keep it.
- Prepare a one-page view of hosting and tool costs, today and at ten times the users.
- Make sure at least two people can deploy, restore a backup and explain each critical system.
On the day
- Answer what you are asked, briefly and accurately. If you do not know, say so and follow up in writing.
- Do not oversell. Reviewers compare your answers with the code and the documents, and inconsistencies cost more trust than honest gaps.
- Have your technical lead in the room. A non-technical founder fielding detailed questions alone is itself a signal.
- Share code through a controlled process agreed with the investor, under a confidentiality agreement.
Common gaps that cause delays
- No IP assignment from an early freelancer or co-founder who has since left.
- The production database or domain registered to a former employee.
- Backups that exist but have never been restored.
- Customer data copied into spreadsheets and personal laptops.
- A large rewrite planned but not mentioned until asked.
Our technology advice service includes pre-raise reviews that work through this checklist with you, and our strategy work can help shape the wider fundraising story. Get in touch a few months before your round, not a few days.
This is general information, not legal advice. Take advice from a lawyer on IP assignment, licensing and data protection questions.
Frequently asked questions
When does technical due diligence happen in a fundraise?
Usually after an investor has shown serious interest, often around the term sheet stage, and before the money is transferred. At early stages it may be a single call with a technical partner. In later rounds it can take a few weeks and involve questionnaires, documents and code access. Preparing months ahead keeps it from delaying your round.
Do investors need to see our source code?
Not always. Many early-stage reviews rely on conversations, documents and a walkthrough of the product. Later-stage investors more often ask for code access, typically for a set period, under a confidentiality agreement, sometimes through a third-party reviewer. Agree the scope and process in writing before giving anyone access.
What if our code has a lot of technical debt?
Most startups do. Reviewers mainly want to see that you know where it sits, why it exists and how you plan to deal with it as you grow. A short written list with priorities and rough effort estimates turns a weakness into evidence of good judgement. Hiding it and having it discovered is far worse.