Your pitch deck says 99.9% uptime. Or sub-second inference. Or "real-time" something. It sounds good in the room, the investors nod, and you move on. Then diligence starts, and one of those numbers comes back as a request: show us the logs.
Founders get caught here constantly. The claim was aspirational, or rounded up, or true on a good week, and now someone technical wants the evidence behind it. The gap between what the deck says and what the metrics show is one of the fastest ways to lose trust in a review, because it makes the reviewer wonder what else was rounded up.
Every technical claim is a promise to produce evidence
Treat each number in your deck as a claim you will be asked to back with data. Uptime figures need monitoring history. Latency claims need benchmark reports or production traces. "Handles millions of events" needs to be visible in your infrastructure. "Real-time" needs a definition and a measurement, because to a reviewer it could mean anything from 50 milliseconds to five minutes.
The claims that get checked most
Reliability and performance numbers get checked first, because they are the easiest to verify and the most commonly inflated. A claim of 99.9% uptime allows about 43 minutes of downtime a month; if your status history shows a four-hour outage last quarter, the claim and the evidence do not match, and now you are explaining the gap instead of the product. Security and compliance claims are next: if the deck says SOC 2, the reviewer wants the report, not the intention to get one. Scale claims come third, and they are checked against your infrastructure directly, so "processes millions of records" needs to be visible in a database or a queue, not just in a sentence.
The cost of a mismatch is not one lost point. A technical review now typically runs two to four weeks at Series A, and a claim that fails verification early tends to lengthen that window, because the reviewer stops taking the rest of the deck at face value and starts checking everything by hand.
Reference customer calls are part of the evidence
Investors increasingly verify technical claims not only in your logs but on calls with your customers. If you tell the room your system saved a client 30% in processing cost, expect the reviewer to ask that client directly. The claim and the customer's version need to match. This is why what belongs on the technical slide of your deck should be things you can defend from two directions: your own data and your customers' experience.
How to make your claims diligence-proof
The fix is not to stop making claims. It is to make only claims you can prove, and to have the proof organized before anyone asks.
Round down, not up
If your uptime over the last six months was 99.4%, say 99.4%, or say "99.9% target." A slightly less impressive number you can prove beats an impressive one you cannot. Reviewers are not comparing you to perfection; they are checking whether your words match your data. A founder whose modest claims all check out builds more trust than one whose bold claims mostly do not.
Assemble the evidence pack in advance
For every technical claim in your deck, have the backing document ready: the uptime dashboard export, the load-test report, the SOC 2 letter, the architecture diagram that shows how the "real-time" pipeline actually works. Putting this together belongs alongside the three-page tech memo that carries you through diligence. When a claim gets questioned and you produce the evidence in the same call, the question closes instead of festering.
Define the fuzzy words
"Scalable," "real-time," "enterprise-grade," and "AI-powered" all mean nothing until you attach a measurement. Before diligence, write down what each fuzzy term in your materials actually means in numbers, and make sure the number is one you can show. A reviewer who hears "real-time means our median end-to-end latency is 180 milliseconds, here is the trace" stops probing. One who hears "real-time means, you know, fast" starts digging.
The trust math
A single unprovable claim does more damage than the claim was ever worth in the pitch. Once a reviewer catches one number that does not survive contact with the evidence, they re-examine every other number with suspicion, and a two-week review turns into four. The founders who move through diligence fastest are not the ones with the most impressive decks. They are the ones whose every claim, checked, turns out to be true or conservative.
If you want to know which of your numbers will survive scrutiny before an investor's advisor tests them, a short technical review can pressure-test your claims against your actual data while you still have room to adjust the deck.
FAQ
What if my real numbers are less impressive than my competitors' claims?
Your competitors' claims may not survive their own diligence either. You are not competing on who states the biggest number in the room; you are competing on who still has a deal after the review. Provable and modest beats impressive and unverifiable every time it reaches a technical reviewer.
Which claims should I drop from my deck entirely?
Any claim you cannot back with a document or a customer who will confirm it. If you cannot produce evidence in the diligence call, the claim is a liability, not an asset. Cut it or soften it to something you can defend.
How early should I build the evidence pack?
Before you start pitching, not before you start diligence. The claims in your deck are already circulating the moment you present them, and you want the backing organized so that a diligence request is a five-minute retrieval rather than a scramble.