Ten years ago a pre-Series A round closed on traction and a conversation. That has shifted. Funds writing $500,000 and up at seed increasingly send an outside engineer to spend two or three days with the codebase before the money moves, and founders regularly discover this at the worst possible moment: after the term sheet, during the part everyone assumed was paperwork.
The good news is that this process is far more predictable than it feels, and it is not an exam on code quality. Here is what actually happens.
What they are really pricing
A diligence reviewer has one job: estimate how expensive it will be to turn this product into something a team can develop. That is it. They are not looking for beautiful code, and they know perfectly well that a pre-seed product was built fast and under pressure — most of them have built one.
What they are trying to establish is whether the twelve engineers in your hiring plan can actually be productive, or whether the first two quarters after the round will be spent on archaeology. That distinction moves real money, because it changes how far the round goes.
The five things they open first
- Can a stranger run it? They will try to get the product running locally from whatever instructions exist. How long that takes is the single most predictive number in the whole review, because it is exactly what every future hire will experience.
- How does a change reach customers? One documented, repeatable path is a strong signal. A process that lives in one person head is a finding, every time.
- What automatically checks the money paths? Not full coverage — nobody expects that. They want to know whether sign-up, payment and your core promise break silently.
- Where is the sensitive data and who can reach it? Customer data, credentials, access. This is the one area where a finding can genuinely stop a deal rather than reprice it.
- What does one person know that nobody else does? Key-person risk. They will ask directly, and they will ask your team separately.
What each finding actually costs you
Founders imagine diligence as pass or fail. In practice it is a pricing exercise, and most findings land in the middle column.
| What they find | What it usually costs you |
|---|---|
| Nothing is written down; setup takes days | A slower hiring ramp in the plan, and pointed questions about your first two quarters |
| Releases depend on one person | A named condition in the round: fix it within a quarter |
| No automatic checks on payment or sign-up | Usually a note, not a blocker — unless you are handling other people money |
| Customer data reachable by more people than necessary | This one can stop the deal. Fix it before anyone looks |
| Only the founder understands the core of the product | Pressure on the hire plan, sometimes a vesting or retention condition |
| The founder was unaware of any of the above | The most expensive finding of all — see below |
The finding that actually does damage
Investors expect a young product to have problems. What they are also measuring, throughout, is whether you know what your own risks are. A founder who says "yes, our release process is one person and here is our plan for that" reads as someone in control. A founder surprised by the same fact in a diligence call reads as someone who does not know what they own.
They are not checking whether your product is perfect. They are checking whether you know where it is not.
This is why the preparation that matters is not cleanup. It is inventory.
How to prepare without pretending
- Run the five checks above on yourself, four to six weeks before you expect diligence. Write down the honest answers, including the bad ones.
- Fix the security item properly. Who can reach customer data is the one finding with the power to end a process. Everything else is negotiable; this is not.
- Write the setup instructions and have someone else follow them. Not the person who wrote them — someone who has never done it. Time the attempt. That number will come up.
- Get the release process out of one head and into a document. Even a rough one changes the conversation from risk to plan.
- Prepare a one-page honest summary: what is solid, what is known-weak, what you intend to do about each and by when. Hand it over at the start.
What to have ready two weeks out
- Setup instructions that a stranger has successfully followed, with the time it took
- A written description of how the product is put together — a page or two is plenty
- The release process, documented, runnable by at least two people
- A list of who can reach customer data, with anyone unnecessary already removed
- Your own one-page assessment: solid, weak, plan, dates
None of this requires rebuilding anything, and none of it is work you would otherwise waste — it is the same work that makes your first engineering hires productive, described in Why Fast-Built Products Get Expensive Right After Funding. Diligence just gives it a deadline.
The part nobody tells you
The reviewer writes a short memo, and the partner reads maybe a page of it. That page is rarely a verdict on your engineering. It is a paragraph on how quickly this team can absorb the money it is about to receive.
Which means the whole exercise is, in the end, about the same thing you are already worried about: whether the product that got you here can carry the team that comes next.
