What a technical due diligence actually examines, the five findings that discount or kill a round, the documents to have ready before the data room opens, and what you can realistically fix in two weeks.
Technical due diligence is the review an investor runs on your codebase and engineering practice after the term sheet and before the money moves. A technical advisor gets read-only access to your repository for one to three weeks and answers one question for the investor: what does this team actually own, and what will it cost to keep building on it? They are not marking your code out of ten. They are pricing risk — and the findings that change a deal are almost never about code quality. They are about IP ownership, undisclosed security incidents, licence exposure, and one engineer who is the only person who understands production.
Key takeaways: Diligence happens after the term sheet, so problems found there cost you leverage, not just time. The five deal-damaging findings are IP you cannot prove you own, secrets or breaches in your history, copyleft licences in a proprietary product, a bus factor of one, and a demo that is not the product. Most are preventable with a week of preparation and paperwork you should already have. Ranges below are INFOCRUD planning figures reviewed in September 2026.
What technical due diligence actually is
It is confirmatory work. The investor has already decided they want to invest — that is what the term sheet says — and diligence exists to confirm nothing about the business is materially different from what you described. The technical portion is one workstream alongside legal, financial, and customer reference checks.
The shape is fairly consistent:
- When: after the term sheet is signed, usually two to six weeks before close. At pre-seed and seed it is often a single conversation with your technical lead; from Series A onward it is a structured review
- Who: a partner with an engineering background, a technical advisor the fund uses regularly, or an external diligence firm. Investors typically pay ₹4–20 lakh for a formal external review, which tells you how seriously the output is taken
- How long: one to three weeks, including a code review, one or two calls with your engineers, and a written report
- What they get: read-only repository access, an architecture walkthrough, and answers to a document request list
The output is a report the investment committee reads. It rarely says "do not invest". It says things like "the platform is buildable but the team has a single point of failure in X" or "IP assignment for the two contractors who built the payments module could not be verified" — and those sentences turn into conditions, escrow, a revised valuation, or a delayed close.
That timing is the part founders underestimate. Before the term sheet you have competitive tension and leverage. After it, you are usually the only deal on the table and every finding is a reason to renegotiate. The work to prepare is the same either way; doing it earlier is simply worth more.
The checklist a reviewer actually runs
| Area | What they look for | What a bad answer looks like |
|---|---|---|
| Repository | One repo of record, real commit history, named contributors | A single "initial commit" containing the entire product |
| IP ownership | Signed assignment from every person who wrote code | "A friend built the first version" |
| Dependencies | Current versions, no known critical CVEs, licences compatible with a commercial product | A lockfile three years old, or an AGPL library in the core |
| Secrets | Nothing sensitive in the repo or its history | An old .env committed in 2024 and never rotated |
| Tests and CI | Tests exist, run automatically, and block a bad merge | A test suite nobody runs, or none at all |
| Access control | Who can reach production, and can it be revoked | Shared root credentials in a spreadsheet |
| Key-person risk | More than one person understands each critical system | One engineer who is the only one who can deploy |
| Infrastructure | Reproducible environments, tested backups, a deploy that is not manual | Servers configured by hand and never documented |
| Data and compliance | What personal data you hold, where it lives, what your policy says | No answer to "where is customer data stored" |
| Architecture | An honest account of what breaks first at 10x | A scalability claim nobody can evidence |
Two things are worth understanding about how this is read. First, reviewers are experienced enough to expect mess — every startup codebase at this stage has shortcuts, and shortcuts that are known and written down read as judgement, not as debt. A tech-debt register is a positive signal.
Second, they are testing whether what you said matches what exists. A founder who says "we know the notification service is fragile, here is the plan" builds credibility. A founder who presents everything as solid, and is then shown the fragile part, loses it across the whole review.
The five findings that kill or discount a round
1. You cannot prove you own your IP
The most common serious finding, and the only one on this list that regularly stops a deal outright. If a freelancer, agency, friend, or early employee wrote code without a signed IP assignment, your company may not own it — and in most jurisdictions authorship defaults to the creator, not to whoever paid.
It compounds: an engineer who wrote your core module while employed elsewhere may have given their previous employer a claim, depending on that contract. Investors cannot fund a company whose main asset has unclear title, so this becomes a closing condition and you are chasing signatures from people you last spoke to two years ago, under deadline.
2. Secrets in your history, or a breach nobody disclosed
Reviewers scan the full commit history, not just the current files. Deleting a .env file in a later commit does not remove it — it sits in the history, readable by anyone with repository access, and the credentials in it are usually still valid.
# scan the entire history, not just the working tree
docker run --rm -v "$(pwd):/repo" zricethezav/gitleaks:latest detect \
--source=/repo --report-format=json --report-path=/repo/gitleaks.jsonRun that on your own repositories this week. If it finds something, rotate the credential first and clean the history second — in that order, because rotation is what actually closes the exposure. An undisclosed past incident found during diligence is worse than the incident itself, because it reframes everything else you said as possibly incomplete.
3. A copyleft licence in a proprietary product
Strong copyleft licences such as GPL and AGPL can require you to release source code for software that incorporates them. In a business whose value is proprietary software, one such dependency in the core product is a genuine commercial problem, and AGPL is stricter still because it can be triggered by offering the software over a network.
Most of the time it arrives through a transitive dependency nobody chose deliberately. Generate a licence inventory of your full dependency tree, know what is in it, and swap anything incompatible before a reviewer builds that list for you.
4. A bus factor of one
If one engineer is the only person who can deploy, the only one who understands the data model, or the only one with production access, that is a valuation risk with a name attached. Investors are buying a team's ability to keep shipping, and this finding says that ability leaves if one person does.
It is also among the cheapest to fix. Written runbooks, a second person who has actually performed a deploy, and access that is granted by role rather than by history will move it materially in a fortnight.
5. The demo is not the product
Features shown as live but stitched together for the pitch, integrations that are mocked, usage numbers that count differently from how you described them. This is the finding that ends processes, because it is not a technical problem — it is a trust problem, and it makes the investor re-examine every other claim.
The defence is simple and unglamorous: say what is built, what is prototyped, and what is planned, and use those words consistently from the first meeting.
Documents to have ready before the data room opens
Assemble these once and diligence becomes a scheduling exercise rather than a fire drill:
- A one-page architecture diagram — services, data stores, third parties, and where customer data lives
- Read-only repository access for named reviewers, granted and revocable
- IP assignment agreements for every founder, employee, and contractor who has written code. This is the one to start on today
- A third-party inventory — services, what each one does, contract terms, monthly cost, and what happens if one disappears
- A dependency and licence list for your full tree, not just direct dependencies
- Security posture — access policy, incident history (including "none" if that is true), backup and restore evidence
- CI and test evidence — a screenshot of pipeline runs is worth more than a coverage percentage
- A tech-debt register — the top ten known shortcuts, their risk, and roughly what each costs to fix
- Infrastructure cost breakdown by environment. If you cannot explain the cloud bill, that is worth fixing first
What you can fix in two weeks, and what you cannot
| Fixable in two weeks | Not fixable in two weeks |
|---|---|
| Rotating exposed secrets and cleaning history | Building meaningful test coverage from zero |
| Updating dependencies with known CVEs | Re-architecting the platform |
| Writing the architecture doc and runbooks | Manufacturing commit history — reviewers notice |
| Cleaning up production access and removing shared credentials | Undoing a data incident you never disclosed |
| Adding CI so tests run on every merge | Replacing a copyleft dependency in a core module |
| Producing the licence and third-party inventories | Getting signatures from people you cannot reach |
| Writing the tech-debt register | Turning a prototype into a shipped product |
IP assignment sits across both columns, which is why it is the item to start on before anything else. The paperwork itself is quick; finding a contractor from 2024 and persuading them to sign is not.
The temptation with the right-hand column is to hide it. Do the opposite — a known gap with a plan and a cost attached is a normal diligence finding. The same gap discovered by the reviewer is a credibility problem.
How to prepare, in three passes
- Phase 01This week — establish what you own. List every person who has written code for the company and check you hold a signed IP assignment for each. Run a secrets scan across full history and rotate anything it finds. These two items cause more deal damage than everything else combined, and neither needs an engineer's whole week.
- Phase 02This month — make the practice legible. One-page architecture diagram, runbooks for deploy and restore, CI running tests on every merge, production access granted by role. Remove the single points of failure you already know about, starting with the person-shaped one.
- Phase 03Before you raise — assemble the room. Dependency and licence inventory, third-party list with costs, security and incident summary, tech-debt register. Have someone outside the team read it cold and ask the questions an investor's advisor would.
None of this is work you would not otherwise want done. That is the argument for doing it before you need it: the same fortnight buys you an operationally better company and removes the findings that would have cost you leverage.
Mistakes founders make in technical diligence
- Treating it as an exam. It is a risk assessment. "Here is what is weak and here is the plan" scores better than a defence of everything
- Letting one engineer handle the whole process alone. It confirms the key-person finding while you are being reviewed for it
- Cleaning up the repository right before access is granted. A flurry of commits days before review is visible and reads as concealment
- Overstating scale. Claims about load and users get checked against infrastructure and logs, and the mismatch is what gets remembered
- Waiting for the term sheet. By then the findings cost you negotiating position, and the preparation takes the same fortnight it always did
Frequently asked questions
At what stage does technical due diligence start happening?
Seriously from Series A. At pre-seed and seed it is usually a conversation with your technical lead plus a light look at the product. That said, angel and seed investors increasingly ask about IP ownership and security specifically, and those are the questions that take longest to fix — so the preparation is worth doing before your first institutional round.
We have no CTO. Who handles this?
Someone technical has to hold the conversation, and it should not be your only developer while their own bus factor is under review. Founders without an in-house technical lead usually bring in a fractional CTO to run the preparation and sit in the review calls — that is one of the more common reasons the role gets hired at this stage.
How much does a technical due diligence cost, and who pays?
The investor commissions and pays for it, typically ₹4–20 lakh for an external firm depending on scope. Your cost is preparation time — one to two engineer-weeks if you start early, considerably more if you start when the request list arrives.
Will messy code lose us the deal?
Rarely on its own. Reviewers expect a startup codebase to carry shortcuts, and messiness is priced as future cost, not treated as fraud. What loses deals is unclear ownership, undisclosed incidents, and gaps between what was claimed and what exists.
Should we run a review on ourselves first?
If you plan to raise in the next two quarters, yes. A pre-diligence review runs the same checklist while you still have time to act on the findings and before they are in a report the investment committee reads. The value is entirely in the timing.
How long does the whole process take?
One to three weeks of review, plus however long your responses take. Teams with the documents assembled answer in days; teams assembling them during the review add two to three weeks to the close — which is where deals lose momentum.
The bottom line
Technical due diligence is not a code quality contest. It is an investor checking that you own what you say you own, that nothing dangerous is buried in your history, and that the team can keep shipping if any one person leaves. Four of the five findings that damage rounds are administrative, and every one of them is cheaper to fix now than under a closing deadline. Start with IP assignments and a secrets scan this week — that is the majority of the risk, and it costs you an afternoon.
If you are raising in the next two quarters and want the findings before an investor's advisor writes them down, that is what a pre-diligence review is for. You can explore Startup CTO in a Box to see how we cover technical ownership at this stage, or book a pre-diligence codebase review and we will run the same checklist an investor would — while you still have time to act on it.
