Founders prepare for the market questions and get caught out by the technical ones. Not because the questions are hard, but because nobody tells you what a diligence engineer is actually looking for. They are not grading your architecture. They are trying to work out one thing: if this company doubles twice, does the software become a liability?
The good news is that the list is short and it does not change much between rounds. Here is what gets checked, and what a good answer looks like.
What they actually look at
Who can change the system
The first question is rarely about code. It is about people. If one engineer is the only person who understands how billing works, that is a risk on the cap table, not just the org chart. Investors ask this in different words. They want to know what happens to the product if a specific person leaves on a Friday.
A good answer is boring. More than one person has touched every important system, the setup instructions work on a new laptop, and decisions are written down somewhere that is not a founder's memory.
Whether the data is defensible
In health, finance, and anything touching children or location, this is the question that can end a deal. Where does personal data live, who can read it, and can you prove who read it last Tuesday? Encryption at rest is table stakes. What people forget is the audit trail, and whether that trail itself leaks the data it is supposed to protect.
What breaks first under load
Nobody expects a seed-stage product to handle a million users. They expect you to know where it stops. “The database is fine to about ten thousand active accounts, then we split reads” is a strong answer. “It scales” is not, and experienced investors hear it as “we have not looked”.
How much of the build you actually own
This one surprises people. If an agency built your product, check what the contract says about ownership before an investor does. The same goes for a no-code platform holding your core workflow, or an AI vendor whose pricing can change under you. Any dependency you cannot replace is a dependency you do not control.
The mistake almost everyone makes
Founders over-prepare the demo and under-prepare the truth. They spend the week before diligence making the product look finished, when the person reviewing it will find the rough edges in twenty minutes and lose trust in everything else you said.
A known problem with a plan reads as competence. The same problem discovered by someone else reads as a surprise, and surprises are what kill deals.
Write down your technical debt before anyone asks. What is fragile, what you would rebuild with more time, what you are deliberately ignoring for now and why. Hand that over early. It costs you nothing, because they were going to find it anyway, and it changes the shape of the conversation from interrogation to planning.
What to do about it now
- Write a one-page summary of how the system fits together. If you cannot, that is the first finding.
- List every third party you depend on and what happens if their price triples.
- Check who legally owns the code, in writing, before you need to know.
- Name the part of the product you would rebuild first, and roughly what it would cost.
- Make sure at least two people can deploy.
None of this requires a rewrite. It requires an afternoon of honesty, written down, well before anyone with a term sheet asks the question.