Technical Due Diligence: What Investors Actually Check
Most founders prepare for technical due diligence the way students prepare for an exam they have already failed. The term sheet arrives, somebody mentions a technical review, and a scramble begins to tidy documentation, revoke old access, and establish who actually owns the domain.
By then the answers are already fixed. A technical review does not test the product. It tests the last two years of decisions, and there is no way to retrofit those in a fortnight.
What the review is really for
An investor running technical due diligence is answering three questions. Can this product carry ten times its current load without being rebuilt from scratch. Is there anything inside it that becomes a legal or security problem after the money moves. And if two named people left tomorrow, would the company still be able to ship.
Every item on every checklist maps back to one of those three. Knowing that makes the process considerably less mysterious, and it makes preparation much easier to prioritise.
The five areas that get examined
Architecture and scalability. Current diagrams, how data moves through the system, where it breaks under load, and whether anyone has actually tested that rather than assuming it.
Code quality and process. Not elegance. Whether there is code review, sensible version control discipline, automated testing on the paths that carry money or data, and a deployment process that does not depend on one person being awake.
Security and data handling. Where personal data lives, who can reach it, how secrets and credentials are stored, and whether any of that matches what your privacy policy already claims in writing.
Intellectual property and licensing. Contributor agreements signed, contractors having properly assigned their work to the company, and no restrictive open source licence sitting inside a product you intend to sell.
Key person risk. Whether critical knowledge is documented or resident in one person’s head, and whether that person has an employment agreement.
The findings that move the price
Some findings kill deals. Most do not. What they mostly do is change terms, and it is worth understanding the difference before you walk into the room.
Unsigned intellectual property assignment from an early contractor is common and completely fixable, but discovering it during diligence turns a clean round into a delayed one while lawyers chase somebody who left eighteen months ago. Undisclosed open source under a restrictive licence is worse, because remediation means rewriting whatever depends on it. Security gaps in a product handling regulated data can convert a straightforward equity round into one with milestones attached to it.
The pattern across all of them is consistent. What damages a deal is rarely the technical problem itself. It is the founder not knowing about it. Investors extrapolate from that, and the extrapolation is not generous. If you did not know about that, the thinking goes, what else do you not know.
Ninety days out
The preparation that works starts about a quarter before you plan to raise, and almost none of it is glamorous.
Run your own review first, ideally with somebody who was not on the build team and has no stake in defending its decisions
Get every contractor and early employee intellectual property assignment signed and filed, including the people who are no longer around
Move domains, cloud accounts, repositories, app store listings and analytics into company ownership rather than personal accounts
Produce a current architecture diagram and a short technical overview that a non engineer on the investment team can follow
Generate a software bill of materials and check the licences inside it against what you are actually allowed to sell
Write down the technical debt you already know about, with a plan and a cost attached to each item
None of this requires new engineering work. It requires a fortnight of unglamorous administration that most companies keep postponing because nothing visibly breaks when they do. The cost of postponing it is invisible right up until the week it is very expensive. A useful test is to ask whether a new engineer joining on Monday could deploy to production by Friday using only written documentation. If the honest answer is no, a diligence team will find the same gap you just found.
Say the hard part first
Founders often try to bury known weaknesses, which does not work. Diligence teams find them, and the discovery is always worse than the disclosure would have been.
The stronger move is to open with your own list. Here are the four things we would fix with more time. Here is what each would cost. Here is why we made the trade at the time. That conversation reads as competence, not weakness. Nobody is funding a perfect system, because none exists at this stage. They are funding a team that understands the system it has and can price its own gaps.
Who sits in the room
Send someone who can answer without rehearsing. That is normally a CTO or a lead engineer rather than a founder relaying answers second hand, because the follow up questions in a technical session go three layers deeper than any briefing document survives.
If nobody on staff can play that role, this is one of the more common reasons companies bring in fractional technology leadership ahead of a round. Not to build anything, but to run the preparation, produce the documentation, and sit in the sessions and answer properly. It is a short, well defined piece of work with a very direct effect on how a round closes.
The version of diligence you want
The best possible outcome is a review that produces no surprises for anybody in the room, including you. That tends to happen at companies that were keeping their house in order for reasons entirely unrelated to fundraising, which is really the whole lesson here. Diligence readiness and operational maturity are the same thing viewed from two directions.
CB Insights has spent years analysing why companies fail, and most of the causes it lands on are decisions rather than accidents. A technical review simply makes those decisions visible to somebody who is about to write a cheque. The companies that enjoy that meeting are the ones who had already looked.
Frequently Asked Questions
Technical due diligence is an independent review of a company's technology, carried out by or for an investor or acquirer. It covers architecture, code quality, engineering process, security, data handling, intellectual property and the technical team, with the aim of identifying risks that financial and commercial reviews would miss.
Most commonly after a term sheet is signed and before funds are released, which is exactly the point where problems are most disruptive. Some investors run a lighter technical review earlier, during the evaluation stage, particularly for products where the technology is the primary asset.
Typically one to three weeks for an early stage company, involving document review, code inspection and a small number of interviews with the technical team. Larger or later stage deals run longer, and anything that surfaces an intellectual property or licensing issue extends well beyond the technical work itself.
Unsigned intellectual property assignments from contractors, restrictive open source licences inside a commercial product, personal accounts holding company infrastructure, absent or unreproducible deployment processes, and critical system knowledge held by a single person with no documentation.
The review is lighter but it still happens, and it is usually more focused on the team and on intellectual property ownership than on code quality. At that stage nobody expects a mature codebase. They do expect the company to actually own what it built.
Whoever can answer technical follow up questions without preparation, which usually means a CTO or lead engineer. Founders relaying answers second hand tend to struggle once the questions go a layer deeper, and hesitation in that room reads as risk rather than as inexperience.
