Most founders I work with assume the technical part of a Series A due diligence will be about their code. They expect a reviewer to open the repo, read the architecture, and either approve or raise concerns about the stack choices. That is not what happens.
A good DD person spends almost no time in the code. They spend their time in the five places around the code where the things that actually kill a Series A tend to live. All five are cheap to fix if you fix them before the diligence starts. All five are expensive to explain after the fact.
Here they are, in the order a sharp reviewer will find them.
One: Bus Factor
The reviewer will ask who can deploy, who can roll back, who can read the on-call dashboard, and who can answer “what broke in production last month and what changed because of it.” If each of those questions has the same name next to it, the DD finds it in the first forty minutes.
Founders usually think the fix is a runbook. It is not. A runbook written by the one person who can deploy is still a bus factor of one. The fix is a second person who has actually deployed. Who has actually rolled back. Who has actually been on-call for an incident. One of those three things in the last ninety days is enough. None of them in the last year is a problem the DD will spot before you do.
Two: Decision Memory
Why Postgres and not DynamoDB. Why Vercel and not AWS directly. Why that specific queue, that specific auth layer, that specific vector database. If the technical founder cannot answer in three sentences per decision, the reviewer assumes the decision was accidental. If the decision looks accidental, every other decision built on top of it also looks accidental, and you are suddenly justifying your entire architecture retroactively in the room.
The fix is not a 40-page architecture document. The fix is one page that names each major component, the alternative considered, and the reason the choice was made. Write it this week for everything that matters. The exercise also tells you which decisions were in fact accidental, and those are the ones you want to be ready to talk about honestly.
Three: Security Floor
The reviewer is not expecting SOC2 at seed stage. They are expecting the floor. API keys do not live in old branches. Prod access that belonged to the contractor who left in April is revoked. There are no shared root logins. There is a log of who has what. Secrets are in a secret manager, not in a .env file committed to the repo in 2023 and never rotated.
Most of these take a weekend to fix if they are broken. The DD cost of leaving them broken is not the finding itself. It is what the finding implies about every other hygiene issue the reviewer has not yet seen. One rotated key tells them nothing. One unrotated key from two years ago tells them the floor is not actually there.
Four: AI Spend You Have Not Priced
Every seed-stage company shipping AI features now has a line in their cost structure that did not exist two years ago. The DD will want to know three numbers. The per-active-user AI cost today. The ceiling at which that cost moves the unit economics by 10% or more. The model call that, if the provider raised prices by 25%, would move more than 10% of your margin.
“We will optimize that later” is not an acceptable answer in 2026. It reads as “we have no idea what this costs us”, which is a different kind of problem than a high cost. A high cost with a plan is a budget line. A high cost without a plan is a bet the investor has to make on your behalf.
If you have not run the numbers, run them this week. The actual answer is often better than you fear. The absence of the answer is what loses the room.
Five: Incident Memory
The reviewer will ask about the last production incident. They are not looking for a clean incident record. They are looking for whether you have one. An incident with a date, a root cause, and a specific thing you do differently now is a sign that the team is watching the system in production. No incidents in the last six months is not a sign of a healthy system. It is a sign that nothing is being measured.
If your honest answer is that you cannot name the last incident, that is the finding. Fix it by actually watching. Pick three metrics the business cares about. Alert on them. Treat the first alert that fires as a real incident even if the cause is small. You will have an answer by the time the DD happens.
The Pattern
None of these findings are about the code. All five are about whether the people and the practices around the code can outlast the specific humans currently holding them in their heads. A Series A investor is buying the company, not the current build. The DD person is their proxy for the question “can this still work when the team grows by 3x and the founder takes PTO.”
If you look at all five findings together, the theme is continuity. Can someone else deploy. Can someone else understand why. Can someone else see what is happening in production. The code can be rough and still pass. The continuity around the code is what the sharp reviewer is actually measuring.
What To Do This Quarter If You Are Six Months From Raising
Pick one week each.
Week one: a second person deploys, rolls back, and reads the on-call dashboard in real production conditions.
Week two: write the one-page decision log for every major component.
Week three: rotate the keys, revoke the stale access, move secrets out of .env.
Week four: price the AI spend and write the ceiling down.
Week five: pick three business metrics, alert on them, let the first alert drive a real small incident review.
Five weeks. The DD stops being about what you forgot to fix and starts being about what you are building on top of a system that is ready for scrutiny. The first version of this work takes nobody more than a day per item. It is the kind of effort founders defer because it does not ship features. It is also the kind of effort that quietly decides whether the Series A conversation moves to terms.
Let’s Talk
If you are six to nine months out from a Series A and want a second set of eyes on the five continuity gaps the DD will find, I do a short technical readiness review that walks exactly these five areas on your actual system and gives you a one-page punch list. No pitch. Happy to look at what you have. Reach out.
