Six months before a Series C close, a CTO walked us through a load test report. 10,000 concurrent users. Response times flat at 120 milliseconds. The graph was beautiful. We asked one question: what was the think time between requests? ...Silence.
The test had been run at machine speed. Zero pause between requests, no session modeling, no realistic traffic shape. It was measuring how fast the server could flush a queue of simultaneous calls, not how the system behaved under actual human load. They re-ran it the following week with realistic behavior. At 3,200 concurrent users, a connection pool on the checkout service saturated. P99 latency climbed to 8 seconds. One queue backed up and stayed backed up for 20 minutes after the test ended. The deal closed, but with a performance remediation plan baked into the term sheet and two senior engineers pulled off roadmap work to execute it.
A load test that doesn't model reality is not a load test. It's a confidence trick you play on yourself.
Why this matters
Investors don't buy your current throughput numbers. They buy headroom. The question is not whether the system handles today's load. It is whether it handles 3x growth without a rewrite, survives an incident at peak, or avoids a surprise infrastructure bill that compresses the margins they just modeled.
Performance failures are expensive in a specific way: they surface under the conditions you least want them. A product launch. A viral campaign. The week after a major partnership announcement. By then the cost is not just engineering time. It is SLA credits, customer churn, and a deal that closes at a discount.
Investors and their technical advisors increasingly ask for load test evidence, not just uptime charts. The question is whether you can prove the system holds up before they wire the money.
What investors look for
Realistic tests, not synthetic benchmarks. A test that floods endpoints at machine speed with uniform payloads tells you almost nothing useful. Investors want evidence that tests model actual user sessions: login flows, searches, cart additions, checkouts, with realistic think times, session durations, and a traffic shape that resembles production. The closer the test is to real behavior, the more the results are worth.
Documented bottlenecks with evidence. Every system has a ceiling somewhere. What investors want to see is that you found yours before a customer did. That means knowing which component saturates first, at what load level, and what the failure mode looks like. A capacity map with concrete numbers beats a general claim that the system "scales horizontally."
SLOs measured under load, not just in steady state. P95 and P99 latency targets should hold at peak, not just at Tuesday morning baseline. If your SLO is checkout responding in under 500ms, that target needs to be tested at 2x current peak.
A capacity model tied to growth. Investors want a simple model: at current ARR growth, when will you hit the next infrastructure ceiling? What does it cost to extend that runway by 12 months? Teams that can answer with data are much easier to price than teams that say "we'll scale when we need to."
Stage and stake: how the lens sharpens
Seed and early A: Basic load tests on critical user journeys are enough. Investors accept that the system is not fully hardened. The key signal is awareness. Can the founders articulate where the limits are and what they would do as they approach them?
Series B and growth: Systematic load testing is expected. Bottlenecks should be documented, not speculated. Capacity models should be tied to ARR projections. P95 and P99 latency targets should be tracked and tested, not just aspirational.
Control buyouts: Buyers may run their own load tests against a staging environment that mirrors production. They will ask for the last six months of test results, correlate them with incident history, and model the infrastructure spend needed to handle 3x current volume. Gaps get priced in.
Patterns and practices worth adopting
Test user journeys, not endpoints in isolation. A checkout flow involves authentication, product lookup, inventory check, payment processing, and confirmation. Testing each endpoint independently misses the compound effect of all of them running under realistic concurrency.
Set performance budgets before you test. Decide what acceptable looks like before you run the test, not after you see the results. P95 under 300ms for checkout. Queue lag under 2 seconds. Without a pre-defined target, every result is open to interpretation and easy to rationalize.
Find the three-layer ceiling. For most SaaS systems, performance limits live at one of three layers: application (thread pool saturation, connection limits), database (query time, connection pool, IOPS), or infrastructure (CPU, memory, network). Testing should identify which layer hits the ceiling first and at what load level.
Profile before you optimize. Flame graphs and slow query logs are more useful than assumptions. The fix for a performance problem is almost never where you expect it. Teams that instrument first and optimize second move faster and spend less.
Red flags that lengthen negotiations
- Load tests run against staging with data volumes far below production
- No documented saturation points or capacity limits for any service
- Tests that model machine-speed requests with no think time or session behavior
- Performance tracked only at P50; P99 numbers unknown or not measured
- No correlation between historical load test results and production incident history
- Capacity planning based on "we'll add more instances" with no model behind it
Two or more of these typically produce a remediation condition or a discount. Three or more, and buyers start asking whether the system can support the growth plan they just paid for.
Mini-Glossary
- Think time: The pause between user actions in a session; critical for realistic load modeling.
- P95 / P99 latency: Response time at the 95th or 99th percentile; a better signal of user experience than averages.
- Throughput: Requests or transactions processed per unit of time.
- Saturation point: The load level at which a resource (connection pool, CPU, thread pool, etc.) becomes the binding constraint.
- Connection pool: A cache of reusable database connections; saturation causes queuing and latency spikes.
- Capacity model: A projection of when current infrastructure limits will be reached, given growth assumptions.
Your turn
What performance problem hit you at the worst possible moment? A connection pool that saturated during a product launch, a database that crawled under realistic load, or a test that looked fine until someone asked the right question? Share the scar. It helps the next team.
Next in the Playbook
Edition 26 explores People Risk and Succession Planning: how talent retention and succession depth show up in diligence, and what investors read between the lines of an org chart. Stay tuned!
Originally published on the Tech Due Diligence Playbook newsletter on LinkedIn.