What investors ask about your infrastructure (and why most founders cannot answer)

A founder in Munich asked me to sit in on a technical due diligence call with a seed fund last spring. He had raised a friends-and-family round, built a product, gotten to forty thousand euros in monthly recurring revenue, and now a seed fund was doing technical diligence before committing. The founder was nervous about the call. He told me he was worried they would ask about his architecture and he would have to admit he was running on a single VPS.

They did not ask about his architecture. They asked six other questions, and he could not answer four of them. The fund passed. The reasoning in the rejection email was vague. “We have concerns about operational readiness at scale.” The founder forwarded it to me and asked what it meant. It meant the investor did not believe the founder could run the system he had built without it falling over the moment real traffic arrived. The investor was probably right. Not because the product was bad, but because the founder’s answers revealed that he did not know how his own system worked under stress.

I have been in enough of these calls now to see the pattern. Investors are not checking whether you run Kubernetes. They are checking whether you understand your own system. The questions are simpler and more dangerous than founders expect.

The question about deploys

The first question, almost every time, is some version of: “Walk me through your deployment process.”

The founders who answer well describe a pipeline. Push to main, CI runs tests, image builds, deploy is automatic, rollback is a previous image tag. Two sentences. The investor nods and moves on.

The founders who answer badly describe a ritual. “Well, I SSH into the server, pull the latest code, run the build, run the migration, and restart the service.” The investor writes something down. I have watched investors write things down during this answer. They are not writing compliments. They are writing the word “manual” and circling it.

I was on a call where a founder said this and the investor followed up with: “What happens when you are on vacation?” The founder paused and said, “I take my laptop.” The investor asked, “What if you are sick?” The founder said, “It has not happened yet.” The investor moved on. The deal did not move on with him.

The point the investor is making with these follow-ups is that a deploy process that depends on one person’s availability is a system with a single point of failure. Investors are trained to find single points of failure. It is the first thing they look for, because it is the first thing that breaks when the company grows. A manual deploy is a single point of failure. An automated pipeline is the absence of one.

The answer that builds confidence is not complicated. It is: “We push to main, GitHub Actions runs our tests and builds a container image, and the deploy is automatic. If something breaks, we roll back to the previous image, which takes about thirty seconds. Nobody SSHes into the server.” That answer takes ten seconds to say and it closes the question. The investor hears: this founder has eliminated the most obvious operational risk before I have to ask about it.

The question about incidents

The second question: “Tell me about your last production incident.”

Founders hate this question. They think it is a trap, that admitting an incident means admitting failure. So they say “we have not had any incidents” or “nothing major.” This is the wrong answer, and it is wrong for two reasons.

First, it is almost certainly not true. Every system has incidents. If you have never had an incident, either you have no traffic or you are not measuring. The investor knows this. When you say “no incidents,” they hear “no monitoring.” That is worse than having had an incident.

Second, the question is not about whether you have incidents. It is about how you handle them. The investor wants to hear: we detected it, we knew what was broken, we fixed it, we wrote a postmortem, we made a change so it does not happen again. That sequence tells the investor that your system is operable, that you have observability, and that you learn from failures. Those are the things that make a system trustworthy at scale.

The best answer I heard a founder give was about a database connection pool exhaustion that took the API down for twelve minutes. He described the alert that caught it, the Grafana dashboard that showed the connection count climbing, the rollback that resolved it, and the runbook he wrote afterward so that the next person who got paged would know what to do. The investor asked to see the runbook. The founder shared his screen. The investor read it, nodded, and asked the next question. The seed round closed two weeks later.

The runbook was not the reason the round closed. But the runbook was the evidence that this founder was running a system he understood, not a system he was hoping would keep working. That distinction is what the investor was looking for, and the runbook was the proof.

The question about monitoring

The third question: “How do you know if your system is down?”

This is the question where founders who have no observability get exposed. The honest answer “a customer emails us” has been given to me by three founders during diligence calls. All three said it with a sheepish laugh. None of the three got the deal.

The answer the investor wants is specific. They want to hear that you have metrics, that those metrics feed alerts, and that those alerts reach a human. They do not need the full Prometheus and Grafana and OpenTelemetry stack explained to them. They need to know that someone is watching the system, that the watching is automated, and that the watching happens whether or not a customer complains.

Here is the answer I tell founders to give, and it is true because I have built it for them: “We use Prometheus for metrics and Grafana for dashboards. We have five alerting rules that cover the failure modes we care about: pod crash loops, error rate spikes, latency degradation, database connection exhaustion, and node resource pressure. Alerts go to a Slack channel that two engineers watch.” That answer takes fifteen seconds. The investor hears: this system is observable. This founder will know about problems before customers do.

The number five is not magic. It is the set of alerts I install for every startup because it covers the failures that actually happen. I have written about this before. The point is not the number. The point is that the founder can describe a specific, finite set of alerts that map to specific failure modes. That description tells the investor that someone has thought about what can go wrong and has instrumented for it. That is what observability means in a diligence call. Not a tool. A posture.

The question about security

The fourth question: “What is your security posture?”

This is the question founders are most afraid of, because they think the answer involves SOC 2 or ISO 27001 or some compliance framework they have not started. It does not. The investor is not asking whether you are SOC 2 certified. They are asking whether you have thought about security at all.

The founders who fail this question say “we use HTTPS” or “our passwords are hashed.” These are true and meaningless. They are the security equivalent of saying “we lock the front door.” The investor is asking whether you lock the back door, whether you know where the windows are, and whether you have thought about who has keys.

The answer that works is a security baseline, described in concrete terms. “We do not run containers as root. We have network policies on every namespace in our cluster. Secrets are managed in a sealed secrets system, not in Git or environment files. Container images are scanned in CI and builds with critical vulnerabilities do not deploy. We have a threat model that identifies our attack surface and the controls we have in place for each vector.” That answer tells the investor you have thought about security as a system, not as a checkbox.

I watched a founder give a different version of this answer on a call. He said, “We have not done SOC 2 yet but we are planning to.” The investor asked, “What have you done?” The founder said, “We use AWS, so their security covers most of it.” The investor moved on. The deal did not happen. The problem was not the missing SOC 2. The problem was that the founder could not describe a single security control he had implemented himself. The investor heard: this founder has outsourced his security thinking to his cloud provider. Cloud providers do not secure your application. They secure the infrastructure underneath it. The application is your problem.

The question about scale

The fifth question: “What happens when you get ten times the traffic?”

This is the question that separates founders who understand their system from founders who have a system they hope will work. The bad answer is “we will scale horizontally” or “we will add more servers.” These are things you say when you do not know the answer. The investor knows this. Horizontal scaling is not a plan. It is a hope dressed up as architecture.

The good answer describes specific bottlenecks and specific mitigations. “Our API is stateless and scales horizontally behind a load balancer. Our database is the bottleneck at roughly ten times current load, and our plan is to add a read replica and move reporting queries off the primary. Our background workers are in a queue, and we can scale the consumer count independently. The thing I am most worried about is our search, which is currently Postgres full-text search and will need to move to a dedicated search system at around fifty times load.” That answer tells the investor that the founder knows where the ceiling is and what is on the other side of it.

I helped a founder prepare this answer for a Series A diligence call. We spent two hours mapping his system’s bottlenecks. He had never thought about it in those terms before. He knew the database was slow sometimes, but he had never quantified when it would break. We did the math. His Postgres instance would run out of connections at about twenty thousand concurrent users. He was at two thousand. The ceiling was ten times out, and the mitigation was a connection pooler, which we installed the next day. When the investor asked the scale question, the founder gave the specific answer. The investor asked a follow-up: “What is the connection pooler you use?” The founder said PgBouncer. The investor nodded. The round closed.

The connection pooler was not why the round closed. But the founder’s ability to describe a specific bottleneck with a specific number and a specific mitigation told the investor that this person understood their system well enough to grow it. That is what the scale question is actually testing.

The question about the team

The sixth question: “Who runs your infrastructure?”

This is the question that tells the investor whether the founder has built a system that depends on them personally or a system that a team can operate. The bad answer is “I do.” The investor hears: this company has a bus factor of one. If this founder gets hit by a bus, the system goes down and nobody knows how to bring it up.

The good answer is “I do, with runbooks, and one other engineer on the team can operate the system end to end.” The runbooks are the key. A runbook is the document that lets someone else handle an incident without the founder on the phone. If the founder can point to runbooks for every alert, the investor hears: this system is operable by more than one person. That is what de-risks the investment.

I tell founders to write runbooks before the diligence call, not after. A runbook written for an investor is not useful. A runbook written because an alert might fire at 3am and the founder might be asleep is useful. The runbook that exists because the system needs it is the same runbook that answers the investor’s question. The motivation is different but the artifact is the same.

The pattern behind the questions

The six questions have a shape. Every one of them is testing the same thing: does the founder understand the system they have built, and can that system survive the founder’s absence? CI/CD tests whether the deploy process depends on the founder’s hands. Observability tests whether the system’s health depends on the founder noticing. Security tests whether the system’s defenses depend on the founder remembering. Scale tests whether the system’s future depends on the founder hoping. Runbooks test whether the system’s operation depends on the founder being awake.

The investors are not looking for perfection. They are looking for awareness. A founder who says “we have a gap in our observability and here is what we are doing about it” is more credible than a founder who says “we have no incidents.” The first founder knows their system. The second is hiding from it.

I have seen founders with scrappy infrastructure pass diligence because they could describe every piece of it, every gap, and every plan. I have seen founders with sophisticated infrastructure fail diligence because they could not explain how it worked. The sophistication was the contractor’s, not theirs. The investor could tell.

The infrastructure questions in a diligence call are not about infrastructure. They are about whether the founder has built something they can hand to a team and a customer base and a load level that is ten times what it is now. If the answer is yes, the investor writes a check. If the answer is “I take my laptop on vacation,” the investor writes the word “manual” and circles it.

If you are a founder heading into a raise and recognizing these gaps, Basecamp exists for exactly this reason: digitalaultis.com/basecamp

The questions are coming. The answers should be ready before the call starts, not invented during it.