T

I have sat on that side of the table a dozen or so times. What I want you to understand is how little of those four days gets spent the way founders imagine.

There is no single technical due diligence checklist a startup founder can work from, because the reviewer is not grading your engineering. They are pricing two risks: whether you own what you claim to own, and whether the company survives losing any one person. Messy code, missing tests and an unfashionable architecture are expected at your stage and get written down without much comment. Ownership gaps and knowledge concentration are the two findings that change a valuation or end a process, and both are visible within about an hour.

What does the investor's engineer look at first?

The first command I run is git shortlog -sne --since="24 months ago".

It takes four seconds and it answers the question the investment committee actually asked, which is who built this and are they still here. If 78% of commits in two years come from one address, I have my headline finding before I have read a line of code, and everything afterwards is confirming or softening it.

Second is the commit graph over time, which tells me whether the team is shipping, whether delivery slowed after a particular month, and whether anything looks reconstructed. Squashed history where every commit lands from one account is worth asking about, and there is usually an innocent explanation, but I will ask.

Third is a secret scan across the full history, not the working tree. gitleaks or trufflehog over every commit takes minutes, runs while I read something else, and it finds things. GitHub reported detecting more than 39 million leaked secrets through its own scanning during 2024, which tells you how ordinary this is and also why nobody accepts "we would never do that" as an answer.

Fourth is dependencies and licences, generated as an SBOM and filtered for copyleft. What I am looking for is GPL or AGPL code compiled into or linked against the product you distribute or run as a service. AGPL-3.0, published in November 2007, extends copyleft obligations to software provided over a network, which is exactly the shape of your business, and a single AGPL library in the wrong place is a question your investor's counsel will not be able to price quickly.

Fifth is infrastructure reproducibility. The question is whether the production environment can be rebuilt from a repository or whether it exists because somebody clicked through a console in 2021 and remembers most of it. A clear picture of how the infrastructure fits together, backed by code, moves this from a concern to a paragraph.

Last is incident history, meaning your postmortems. Having none is a worse signal than having several bad ones, because a company with zero recorded incidents in three years is either not looking or not saying. Blameless writeups with named actions and dates read as maturity, and I have upgraded my overall assessment on the strength of a good postmortem more than once.

What gets flagged, and what actually kills a round?

Nearly everything found in diligence is survivable and expected. The distinction that matters is between findings that get priced and findings that cannot be priced.

The bottom two rows are the ones to spend your preparation on, and neither is really an engineering problem, which is why engineering teams under-prepare for them.

Missing IP assignment is the quietest deal-killer in the list. If a contractor wrote a meaningful part of your product without a signed agreement assigning that work to the company, then in many jurisdictions the company does not own it, regardless of what anyone intended or what was invoiced. Same applies to a technical co-founder who left in year two, and to a founder who wrote the first version before the entity existed. This is not exotic. It is common, it is fixable when the person is reachable and willing, and it becomes very hard when they are neither.

The version of this I have seen cause the most damage was mundane. An agency built the original billing module under a short statement of work that covered delivery and payment terms and said nothing about ownership. The agency had since been acquired, which meant the counterparty who could sign a retrospective assignment was a legal department at a company with no relationship to the founders and no incentive to move quickly. Two engineers had rewritten most of that module since, but not all of it, and establishing which lines survived from the original delivery took longer than the entire rest of the review. No one involved had made a mistake. The paperwork simply predated anybody thinking about an exit.

Payment is not assignment, and that surprises people every single time. In the absence of an explicit written transfer, an invoice marked paid establishes that a service was bought rather than that copyright moved.

Licence contamination sits next to it for the same reason. Both convert an engineering detail into a question about whether the asset being purchased is actually the asset on the term sheet, and that is the only category of question an investment committee is genuinely unable to wave through.

Why is a single-understander codebase the worst engineering finding?

Because it is not an engineering finding at all by the time it reaches the people deciding.

An investor is buying future output. If one person holds the entire model of how the system works, the company's ability to produce that output is a function of one individual's continued goodwill, health and employment. That is a valuation risk, and valuation risk is the only kind the investment committee is equipped to act on. Code quality is a cost estimate. Key-person concentration is a probability of the thing being worth much less.

The mechanism is worth stating plainly, because founders often hear this as a criticism of the engineer rather than of the arrangement. Nothing about it implies the person is doing anything wrong. They are usually the reason the company exists. The finding is that the company has not converted what they know into something transferable, and that is a management decision rather than an engineering one.

It also compounds with a fact reviewers know and founders sometimes forget: this person is now more marketable than they have ever been, because a funded round means a hiring budget elsewhere too. If that resignation lands during or shortly after the process, the thirty days after a sole engineer resigns become a diligence problem and an operational one simultaneously.

What happens to a finding after the call?

Understanding how the report travels explains why disclosure timing matters so much.

The reviewer writes up findings with severities, that document goes to the partner, and the partner takes a summary into an investment committee meeting you are not in. By the time a finding reaches the people making the decision it has been compressed into a line or two, stripped of the context you would have supplied if anyone had asked. A nuanced observation about a legacy module becomes "ownership unclear on part of the core product". Both statements are true. Only one of them is in the room.

You usually get one chance to add context, and it comes during the call rather than after the report. Anything you have not said by the end of that conversation is unlikely to reach the committee in your words. Founders who understand this front-load everything awkward into the first hour, on purpose, and it consistently produces better outcomes than the instinct to answer only what is asked.

The severity language matters more than the finding itself for the same reason. "Key-person risk, unmitigated" and "key-person risk, mitigation in progress, runbook complete and second engineer deploying since March" are the same underlying situation described twice, and the second one survives compression intact.

What can I fix in four weeks, and what can't I?

Sequence the preparation by what is unfixable later rather than by what is embarrassing now.

Chain of title comes first and it is document work with an engineering input. Run git shortlog -sne over the entire history, take every name it returns, and match each one against a signed agreement assigning their work to the company. Every founder, employee, contractor, agency and the friend who helped for three weekends in 2019. Where a signature is missing, get one now, while the relationship is warm and before anyone knows a round is happening. This is the highest-value fortnight of preparation available and almost nobody does it first, because it does not feel like engineering.

Secrets come second, and the goal is different from what people assume. Run a full-history scan, rotate every credential it surfaces, and write a short dated note recording what was found, what was rotated and when. You cannot remove the finding. Rewriting history with git filter-repo does not help once the repository has been cloned or forked, and the diligence report will record what was present regardless. What you can do is convert it from a process gap into evidence of a functioning process, which is a completely different conversation on the Friday call.

Licences third. Generate an SBOM, filter for GPL and AGPL, and check whether anything copyleft is linked into what you distribute or serve. Most findings here are in build tooling and are harmless. The occasional one is in the product and needs replacing, which is a real piece of work you would much rather discover four weeks before diligence than during it.

Key-person mitigation fourth, and partial credit counts. Write the architecture decision record, write the deploy runbook, and have a second engineer perform a production deploy while the first watches. Being able to say "two people have deployed this month, here is the runbook" changes the finding from a risk to a mitigated risk, and that adjustment is available in a fortnight.

What cannot be fixed in four weeks: test coverage, architecture, and incident history. Do not attempt them. A test suite assembled in three weeks reads worse than no test suite, because a reviewer can see the commit dates and will conclude you are managing the appearance rather than the system. The same is true of backdated documentation. I have never seen that work and I have several times seen it noticed, which converts a routine finding into a question about candour, and that is the most expensive trade available.

The strongest position in the room is a written list of your own known weaknesses with a plan and dates against each. Handing that over on day one is disarming, it is faster than being asked, and it makes every other thing you say more credible. Much of it comes out of the same exercise as a technical debt audit, which is worth running before the term sheet rather than after.

A clean diligence report has never closed a round on its own. A bad one has killed several. This work is downside protection, it should be budgeted as insurance rather than as growth, and the correct amount to spend on it is therefore modest and bounded. Pre-diligence audits are something we sell, which is exactly why it is worth saying that a founder with four focused weeks and the list above recovers most of the value without engaging anyone. Bring in help when the estate is genuinely complicated, or when nobody internally has time to run it properly, and not because the term sheet made everyone anxious.

If the process spreads into questions about enterprise customers and their security requirements, which it often does when revenue is concentrated in a few large accounts, that sits inside the broader set of architecture problems attached to revenue.

Questions founders ask when the term sheet lands

What do investors actually check in technical due diligence? Commit history and its concentration, secrets in git history, dependency licences, whether infrastructure can be rebuilt from code, and your incident record. Code quality gets looked at and rarely decides anything.

What are the biggest technical due diligence red flags? Missing IP assignments from past contributors, copyleft licences inside the distributed product, and a codebase only one person understands. Those three sit in a different category from the rest, because they affect what the company owns and whether it keeps producing.

How long does technical due diligence take? Usually three to five days of reviewer time across one to three weeks of calendar, with a written report and a call. Larger cheques and acquisitions run longer and pull in legal review of the same material.

Can we fix bad test coverage before diligence? Not credibly in four weeks. A reviewer reads commit dates, and a test suite that appears the month before a process reads as management of appearances, which costs more than the original gap.

Should we tell investors about our technical debt? Yes, in writing, on day one, with a plan and dates. Disclosed weaknesses get priced. Discovered ones get investigated, and the investigation is the part that damages you.

Run git shortlog -sne this afternoon and hold the output next to your folder of signed agreements. If a name appears in the first list and not the second, that gap is the most valuable thing you will fix this quarter, and it gets harder to fix every month.