Preparing for technical due diligence: a 90-day plan

Ninety days is enough time, if you spend it in the order a reviewer reads. The first thirty go on paperwork that is cheap now and expensive under deadline. The next thirty on documentation and on the knowledge that currently lives in one head. The last thirty on security basics, the folder you hand over, and a rehearsal with somebody willing to be blunt.

Almost all of it is obvious. Teams still fail on it, because obvious work has no deadline until somebody else sets one. Seven red flags that stop a funding round covers what gets found in the room. This is the sequence for making sure you find it first.

A pre-raise engineering plan is the work that turns diligence into a confirmation of what you already said rather than a discovery.

The order the work goes in

Two rules set the sequence. Do first what is cheapest now and dearest later: a licence swap in March costs a fortnight of somebody's attention, and the same swap surfacing in June becomes a condition of closing. Conditions get priced.

Start early on anything that takes calendar time. Chasing a signature from a contractor who left two years ago is not hard work, it is slow work, and it lands on the critical path because nobody files it as work.

Documentation comes after both, because writing is quick when you have the facts and slow when you have to go and find them. A licence inventory that already exists turns the IP document into an afternoon; without one, the same document takes a fortnight.

Security and the data room go last. They assemble what the earlier work found, and the rehearsal at the end is only useful once there is something to rehearse against.

The ninety days at a glance

Nine items. Anything not on that list is probably not worth doing before a raise.

Days 1 to 30: the sweeps

Start with the dependency tree. Generate the full tree, with a licence recorded against every package. Most of it will be permissive and dull. What you are hunting for is copyleft in anything you distribute, a package carrying no licence at all, and a component whose terms changed under you in a version bump. Date the list and name who reviewed it. Provenance is a standard question now, including for code written with AI tools, and "we reviewed it like any other code, here is the trail" is a complete answer when it happens to be true. There is more on that in open-source licences and AI-written code.

Next, IP assignment. Everyone who has ever committed code needs an assignment in writing: founders, employees, contractors, the agency that built the first version, the friend who helped for a weekend in 2023. Then check that the repositories belong to the company organisation rather than a founder's personal account, and that the domain, the cloud account and the app store listings are in the company name. A lawyer will not let a round close over an unassigned contributor, and that contributor is usually contactable in March and unreachable in June.

The access audit takes an afternoon and is the cheapest thing here. List every system with production access, name every human who holds it, and remove the people who left. Confirm that at least two people can reach anything the company cannot operate without: the registrar, the cloud account, the payment processor, the identity provider. It answers the first key-person question before anyone asks it.

Days 31 to 60: the seven documents

Technical due diligence reviews cluster into seven areas, and the list barely varies between firms: architecture, code quality and delivery, team risk, security, IP and licensing, data and AI exposure, roadmap. Write one document per area, one to three pages, each dated. The architecture note should say what you chose and what you rejected, because a reviewer learns more from a rejected option than from a diagram. Put in a decision you got wrong and reversed. A record that is uniformly correct reads as one written for the reader.

Specifications carry more weight than founders expect. On a healthcare platform we build, they sit against the codebase. The part reviewers find interesting is the non-goals: a short list per specification saying what was deliberately not built, which mechanism from an earlier platform was not ported, and what would trigger porting it later. A scope boundary with a reason attached is a decision record. One that says out of scope is a shrug.

Days 31 to 60: key-person cover and honest tests

Key-person cover is the finding that reprices a round, and the question that ends diligence calls is what happens when your CTO leaves. The answer that survives contact is an artefact. On the platforms we build that means written engineering conventions kept in the repository, decision records with dates and named authors, and a lessons log per feature area. The log records what shipped and the trap in it. All three stay current because changes are reviewed against them, and a stale rule draws a review comment within days.

Test honesty is the piece people fake. Coverage percentage is the number founders quote and reviewers discount: it says how much code ran, not whether anything would have failed. What survives a follow-up question is which paths are covered. Are the money paths guarded by tests that break when the behaviour breaks, and would the last few production bugs have been caught by anything in the suite?

We could quote a test-to-code ratio off the platforms we build and a reviewer would be right to shrug at it. Coverage theatre is a suite that asserts a function was called. It moves the number, catches nothing, and a reviewer finds it in ten minutes by deleting a line and watching the tests stay green.

Days 61 to 90: security, the folder and the rehearsal

Security basics are boring by design. Multi-factor on every account that can reach production or money. Secrets held in a manager and kept out of the repository. Dependency scanning that runs in the pipeline. A backup that has been restored at least once as a test, with the date written down. An access review with an owner's name on it. A written incident process, even a single page, naming who decides. Reviewers check whether routine work has a routine, because a control that only happens when somebody remembers it is not a control.

Assemble the data room folder before the raise starts. Ours would hold the seven area documents, the dependency and licence inventory, the IP assignment index and the access list with owners. It would also hold a testing and continuous integration summary and the architecture note with its decision records. A list of third parties and model providers, with what data crosses the boundary, goes in too, along with a roadmap separating what is bought from what is built.

Leave out anything naming a customer, any credential, and any incident detail beyond a short summary. Then order it so a stranger finds one item in under a minute: response speed gets read as a proxy for how the company is run, fairly or not.

Then rehearse it, which is the step everyone skips. Give the folder to a technical person who does not work for you, and ask for the three worst things in it. Two days of their time, and someone whose job is to disagree reads the work before the people who matter do.

What we would leave alone

Ninety days is not enough for a rewrite, and diligence does not reward one. We would not start a framework migration, and we would not chase a coverage number. A reviewer is forming a judgement about whether this team ships and explains itself, and a half-finished migration answers both questions badly. The same goes for the tidy-up branch that renames things across a thousand files the week before the data room opens. It wrecks the readability of the commit history, which reviewers trust because nobody curates it.

Two more to skip. Buying a compliance certification you do not need yet, which costs a quarter and answers a question nobody asked. And documenting systems you intend to delete: name them, put a date beside them, and move on.

The caveat is that this list assumes the code is roughly sound. If the product will not scale past the next tranche of customers, ninety days of paperwork makes that finding arrive more clearly. Still the outcome you want, just not one anybody enjoys.

Questions about the ninety days

What if we have thirty days rather than ninety?

Do the sweeps and the folder. Licence inventory, IP assignments, access audit, then whatever documentation you can write from what you already know. Skip the test work, because a suite written in a fortnight looks like one. Say what you have not done and when you will do it.

Should we tidy the code before a raise?

Assume a technical adviser reads a sample and a tool reads everything. What gets read closely is usually the commit history, the test suite and the documents, because those show how work happens. Spend the time on the trail and leave the tidy-up branch alone.

Does AI-written code count against us?

Only if you cannot say what was reviewed. The question is review, not authorship, so show the review record behind each change. That answers it better than a claim that no AI tool touched the codebase, which is rarely true and easy to test.

Who should own this plan?

One person with the authority to say no to feature work for a quarter. In a small company that is usually the CTO, which is awkward, because they are also the answer to the key-person question. Give them a fixed day each week, or it slides by week three.

Should we pay for an external technical audit?

Worth it when the round hinges on a technical claim you cannot evidence yourselves, and a pre-raise technical review is one way to get that, from £6,500. Otherwise the money goes further on the dry run: two days of an outsider's attention surfaces most of the same findings, and the findings stay private.