The 90-day pre-raise engineering 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 rather than effort. 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 precisely 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 are assembly rather than discovery, 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 all of it rather than the top level, 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. Where code came out of a coding agent, note that too, because provenance is a standard question now 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 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, 40 of them sit against a codebase of roughly 60,000 lines, about one line of specification per ten lines of code. The part reviewers find interesting is not the requirements. It is the non-goals: eight to thirteen bullets 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 rather than a reassurance. On the platforms we build that means a short instruction file at the root of the repository, per-area files below it, decision records with dates and named authors, and a memory file per feature area recording what shipped and the trap in it. One platform carries 81 of them. They stay current because agents load them every session; a stale rule produces broken work within days rather than a wrong page within a year.

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 our own platforms 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 rather than in the repository. Dependency scanning that runs in the pipeline instead of when somebody remembers. 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 are not looking for sophistication. They are checking 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 rather than during it. Ours would hold the seven area documents, the dependency and licence inventory, the IP assignment index, the access list with owners, a testing and continuous integration summary, the architecture note with its decision records, a list of third parties and model providers with what data crosses the boundary, and 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. We run the internal equivalent before a release: separate review passes by role, one reading as product owner, one as architect, one as code reviewer, with findings triaged round by round and folded back into the specification. 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 precisely 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 honest caveat: 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 rather than more slowly. 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 a suite written in a fortnight. Say what you have not done and when you will do it.

Do investors read the code?

Assume a technical adviser reads a sample and a tool reads everything. What gets read closely is usually not the code: it is the commit history, the test suite and the documents, because those show how work happens. Prepare the trail rather than a tidied branch.

Does AI-written code count against us?

Only if you cannot say what was reviewed. The question is provenance and review, not authorship. A commit trail naming the agent as co-author alongside a human reviewer answers it better than a claim that no agent 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 rather than a background instruction, 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. 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.