Nobody on your board woke up thinking about database migrations. They woke up thinking about revenue, burn rate, and whether the next funding round will close. If you walk into that room talking about latency percentiles, you’ve already lost.
I learned this the hard way at the fintech startup. We needed a serious infrastructure overhaul. I knew it. My team knew it. But our investors didn’t speak in uptime and throughput. They spoke in money. So I had to learn their language.
Talk money or don’t talk
Every infra pitch boils down to one of four things: it makes money, saves money, reduces risk, or lets us ship faster. That’s it. Pick the frame that fits and lead with it. Not with the technology. Not with the architecture diagram. With the business outcome.
At the fintech startup, we were heading into a period where marketing had big traffic projections. Our system couldn’t handle it. I didn’t pitch “we need to re-architect our data pipeline.” I pitched “we’ll lose paying users in Q3 if we don’t act now.” Different sentence. Same project. Completely different reaction in the room.
Risk is the easiest sell
When downside is obvious, risk framing writes itself. Quantify the probability of an outage. Estimate the cost. Multiply. That number gets attention fast because nobody wants to be the one who ignored a preventable disaster.
Growth constraints work too, but you need credible projections. Vague “we might need to scale” doesn’t cut it. Show the wall you’re about to hit and the revenue sitting on the other side.
Velocity framing is underrated. If your deploys take two hours and engineers sit idle waiting, that’s burned salary. Translate it. “We’re losing 40 engineer-hours a week to deployment bottlenecks” hits harder than “our CI/CD pipeline needs work.”
Do the math, even if it’s rough
A proposal without numbers is just an opinion. I’ve seen smart engineers lose budget requests because they couldn’t answer “what does this cost us today?” Document the current state in dollars and hours. Then describe what changes, in the same units.
Keep the ROI dead simple. Investment. Expected annual benefit. Payback period. If your assumptions are honest and explicit, rough math beats no math every single time.
Structure for skimmers
Executives don’t read proposals. They skim them. One paragraph up top: what you want, why, and what it’s worth. Then a short problem statement in business terms. Proposed solution with minimal technical detail. Quantified impact. Cost. Timeline. Risks and mitigations. Alternatives you considered and rejected.
That order matters. Bury the ask on page three and it never gets read.
Where I’ve seen pitches die
Being too technical. Your CFO doesn’t need to understand container orchestration. They need to understand what it changes for the business.
Skipping quantification. “Better reliability” means nothing. “$200K in avoided incident costs per year” means something.
Ignoring tradeoffs. If this delays a feature, say so. Explain why the trade is still worth it. Pretending there’s no cost makes you look naive.
Asking for everything at once. Phase it. Get a win. Use that win to fund the next phase.
And the killer: not following up. If you don’t report results after getting funded, you’ve just burned your credibility for the next ask.
Keep the conversation going
Don’t wait for budget season. Share metrics regularly. When an incident happens, quantify the damage. When delivery speeds up after an investment, show the numbers. Make infrastructure value visible all the time, so the next request feels like an obvious yes instead of a surprise ask.
Infrastructure is a business investment. Treat it like one and it gets funded. Treat it like a technical hobby and it doesn’t.