Five questions before the investor's engineer opens your code
Infinia ยท
You have a raise on the calendar. The deck is close. The numbers finally tie out.
Then, somewhere between the second meeting and the term sheet, the investor says:
"Great. We'll just have someone take a look at the tech."
That someone is an engineer you've never met. They'll spend a few hours with your codebase, your infrastructure and probably your lead engineer. Then they'll write a short memo your investor reads before deciding.
You won't be in the room when it's written.
So before they open the code, make sure you can answer these five questions in one sentence each.
Not "let me check with the team." Not "I think so." One sentence.
1. Can someone explain our architecture on one page?
The main services, where the data lives, what talks to what, and what breaks if one piece goes down.
If the only map of your system is in someone's head, the investor's engineer has to build it from scratch. They'll draw their own conclusions while they do.
The one-sentence answer sounds like this: "Yes. Here's the diagram, and our lead engineer can walk you through it in 20 minutes."
2. Who has access to production, and how do we remove it?
This is the question founders are least ready for, and one of the first a technical reviewer asks.
How many people can reach the production database? Does anyone who left the company still have credentials? Are secrets in a vault, or in a shared document from 2023?
Nobody expects a $2M ARR company to have bank-grade security. They do expect you to know who holds the keys.
3. What happens when something breaks at 2am?
Not whether things break. Everything breaks. The question is what happens next.
Who gets alerted? How do you find out before a customer does? When did you last restore from a backup, and did it work?
An untested backup isn't a backup. It's a hope, and an experienced reviewer will ask whether you've tested it.
4. How much of this lives in one person's head?
Every startup has one engineer who understands how the pieces fit. That's normal at this stage.
It becomes a risk when that person is the only one who can deploy, debug the billing system, or explain why the data model looks the way it does.
Investors are buying the next three years of the company. If one resignation letter could stall the product, they'll price that in.
5. What have we shipped that nobody really reviewed?
This question is newer, and it's getting asked more.
AI coding tools let small teams ship far more than they used to. That's a real advantage. But a lot of that code was skimmed, not studied. It works, and nobody can fully explain it.
You don't need to apologise for using AI. You need to know where the unreviewed code is, which shortcuts you took to ship fast, and which of them will cost you later.
A team that keeps a written list of its shortcuts looks disciplined. A team that discovers them during diligence looks like it's hiding something, even when it isn't.
Here's why it matters
When founders answer these quickly, technical diligence is a formality. The memo says "sensible choices for the stage, known risks, clear owner." The deal moves on.
When they don't, diligence turns into an investigation.
The reviewer asks for access to more systems. Then a call with the lead engineer. Then a follow-up call. A week goes by. The memo comes back with phrases like "key-person risk" and "limited visibility into security posture."
The investor doesn't say no. They ask for a lower valuation, an extra condition, or "a bit more time."
Or they just go quiet.
Tech debt isn't the problem
Every startup has tech debt. Reviewers know that, and most of them expect it. Some of the best-run companies at $2M ARR have plenty, because they spent their time on customers instead of polish.
What a reviewer is really testing isn't whether your code is perfect.
It's whether anyone owns it.
"We have some debt in the billing service, here's why, and here's the plan" is a good answer.
"I'm not sure" is the answer that hurts, because it tells the investor that nobody is responsible for the technology they're about to fund.
If you're stuck on two or more
If you can't answer two or more of these in one sentence, it isn't a code problem.
It's an ownership problem.
Most founders at $1M to $5M ARR don't have a CTO. They have a strong lead engineer, a busy team, and a founder answering technical questions at 11pm. That works until someone from outside starts asking.
You don't need a $250K full-time CTO before your raise. You need someone who owns these five answers before the investor's engineer asks for them. For most companies at this stage, that's a few days a month.
A part-time CTO.
Which one is hardest for you?
Before your next raise, go through the five with your lead engineer. Answer each one out loud, in one sentence.
The one you hesitate on is where the memo will start.
Infinia introduces founders to fractional CTOs who own a number, not a calendar. One introduction, free.