Cost Justifying Platform Investments, The CFO Friendly Pitch

TL;DR — Build a unit economics model. Anchor on engineer-hours and cloud-dollars. Show payback under 18 months. Skip “developer velocity” as the headline. The CFO already has a vocabulary for this, use theirs.

Platform engineering is having a strange moment in late 2024. The discipline has matured, the patterns are well-understood, and the value is obvious to anyone who has watched a team try to ship without one. And yet the budget conversation is harder than it has been in years. Every CFO I have talked to in the last six months has the same question. “We spent a lot on platform work over the last two years, what did we get for it?”

The teams that have a clean answer to that question are getting funded. The teams that do not are watching their headcount migrate to AI initiatives that have better narratives. This is not a tragedy. It is the natural consequence of platform teams that never built the financial muscle to defend their work. The good news is that the muscle is teachable.

This is the post I would have given my platform lead two years ago. It is the version of the business case that has actually survived contact with finance committees, not the version that lives on a Notion page and gets read by nobody. Some of the math is uncomfortable. The discomfort is the point.

Start with the unit economics

The single biggest mistake platform teams make is leading with capability instead of unit economics. “We are building an internal developer platform” is a capability. The CFO does not buy capabilities. They buy unit economics.

The unit you want to anchor on, in almost every case, is the engineer-hour. Specifically, fully-loaded engineer-hour cost. A useful working number for a US-based senior engineer in late 2024 is somewhere around $150 to $200 per hour fully loaded. Adjust for your geography. For a 50-engineer org, that is roughly $15M to $20M of annual engineering capacity. Anything that recovers 5% of that capacity is worth $750k to $1M a year.

## Unit Economics Worksheet

| Input | Value | Source |
| --- | --- | --- |
| Engineers in org | 50 | HR roster |
| Fully loaded cost per engineer-hour | $175 | Finance + benefits ratio |
| Working hours per year per engineer | 1,800 | After PTO/holidays |
| Annual engineering capacity ($) | $15.75M | Calculated |
| Current % of capacity on infra plumbing | 20% | Survey + Linear/Jira analysis |
| Target % after platform investment | 8% | Industry benchmarks |
| Capacity recovered annually | $1.89M | Calculated |
| Platform team cost (5 engineers + tools) | $1.4M | Build estimate |
| Year 1 net benefit | $490k | Calculated |
| Payback period | ~9 months | Calculated |

That table is the entire business case. Everything else in your deck supports it. The CFO can poke at every row, and you should have a defense for each one. The current-percentage row is usually the weakest. Bolster it with data from your issue tracker, your team surveys, and ideally a time-tracking study you run over two weeks. Yes, time tracking is unpopular. Run it anyway. Two weeks of moderate annoyance is worth the credibility.

Cloud cost is the other half

Engineer-hours are the bigger number for most platform investments, but cloud cost is the more visible one. CFOs see the AWS bill every month. They do not see the engineer-hour bill. A platform pitch that ignores the cloud number is missing the easier half of the case.

## Cloud Cost Recovery (annual)

| Lever | Estimated savings | Risk |
| --- | --- | --- |
| Consolidate dev/staging environments | $180k | Low |
| Rightsize over-provisioned services | $240k | Low |
| Reserved instances + savings plans | $310k | Low |
| Spot for batch workloads | $90k | Medium |
| Multi-tenant ML serving | $400k | Medium |
| FinOps tagging + chargeback | $0 direct, ~$200k via attribution | Low |
| Total | ~$1.2M | |

A few things to note. Tagging and chargeback have no direct savings, but they create the visibility that lets every team make better decisions, which compounds. Always include them, with the explicit note that the savings show up in someone else’s column. CFOs appreciate that honesty.

For the rigor underlying these levers, the FinOps Foundation framework is worth the read. It is not glamorous, but it is the lingua franca finance partners are increasingly fluent in, and aligning your pitch to it pays dividends.

Build a payback model, not just an ROI number

ROI as a single number is suspicious to anyone who has lived through a few finance reviews. Payback period, on the other hand, is intuitive. “We spend $X now, we get $X back in Y months, and after that it is profit.” The shape of that statement is what a CFO uses to compare investment options.

## Payback Model (monthly, in $k)

Month   Investment    Recovered    Cumulative
1       -200          0            -200
2       -150          20           -330
3       -100          40           -390
4       -50           80           -360
5       -50           120          -290
6       -50           160          -180
7       -50           180          -50
8       -30           190          110     <- payback
9       -30           200          280
12      -30           220          830
18      -30           240          1,940

You will be wrong about the exact numbers. That is fine. What matters is that the shape of the curve is defensible and the payback month is under 18. Anything beyond 18 months will lose to the AI initiative or the customer-facing feature unless you can show a strong strategic argument.

For more on framing the strategic argument alongside the numbers, see Translating Business Impact into Architecture Decisions.

Sensitivity, the section that earns trust

Every CFO I have worked with asks the same follow-up. “What if you are wrong about the recovered capacity?” If your answer is “we will deliver,” you have just lost some credibility. The correct answer is a sensitivity table.

## Sensitivity Analysis

| Capacity recovery | Annual net benefit | Payback |
| --- | --- | --- |
| 12% (assumed) | $490k | 9 months |
| 8% (conservative) | $200k | 14 months |
| 5% (downside) | -$80k | 22 months |
| 15% (upside) | $740k | 7 months |

This table does two things at once. It acknowledges that you might be wrong, which builds trust. And it shows that even under conservative assumptions, the project is still net positive. The downside row is the most important one. Be honest. If your project is genuinely a coin flip at the conservative assumption, the CFO needs to know that, and you need to know that you are not yet ready to pitch.

The narrative wrap

Numbers without narrative are noise. Narrative without numbers is hope. The pitch needs both. The narrative I have found most effective has three beats.

Beat one, the cost of doing nothing. Quantified. “If we ship nothing here in 2025, we will need to hire ~12 more engineers to maintain our current shipping cadence, which is $2.4M of headcount and 6 months of recruiting.”

Beat two, the bet. Specific. “We invest $1.4M in a platform team for the year. They build three things: a self-service environment provisioner, a standardized service template, and an internal cost-attribution dashboard.”

Beat three, the proof. Pre-committed. “We will measure success on three metrics, reported monthly. Engineer-hours on infra plumbing, mean time to first deploy for new services, and total cloud spend per service. If we are not on track by month 6, we shut it down.”

That third beat is the one most teams skip and the one that gets the proposal funded. “We will shut it down if it does not work” is a powerful sentence. It tells the CFO you take their money seriously. It also tells your team that the work has stakes, which usually makes the work better.

The DORA research is the canonical external source if you need to defend the metrics you pick, especially the deploy-related ones.

Common Pitfalls

Leading with “developer experience.” It is real, but it is downstream of the numbers. Translate it into engineer-hours recovered before you put it in the deck. CFOs do not buy experiences.

Comparing to a fictional baseline. “Without this investment, productivity will decline 30%.” Numbers without a credible mechanism are dismissed on sight. Always show the mechanism. Decline why? By what process? Cite a comparable.

Picking 3-year ROI as the headline. Three-year ROI is a wonderful number that nobody believes. Lead with payback under 18 months. Three-year is the supporting evidence.

Ignoring opportunity cost. Every dollar that funds the platform team is a dollar that does not fund something else. Acknowledge what is being deprioritized and why your project is the right choice. The CFO is going to ask anyway. Get there first.

Confusing capability with outcome. “We will build a service catalog” is a capability. “Teams find and reuse existing services, reducing duplicate builds” is an outcome. Always pitch outcomes.

Skipping the post-mortem on the previous spend. If your org has spent on platform before, the CFO will ask what happened. Have a clean, honest answer ready. “We delivered X, missed Y, and here is what we learned.” Dodging this question is the fastest way to lose the room.

Wrapping Up

Platform engineering is not in crisis. The narrative has shifted, that is all. The teams that ship in 2025 will be the teams that learned to write the business case in the language the budget owners speak. That language is unit economics, payback period, sensitivity analysis, and pre-committed metrics. None of it is glamorous. All of it is teachable.

If you do nothing else this quarter, build the unit economics worksheet for your team’s work. Even if you do not pitch it. The act of building the model is what surfaces the questions you cannot yet answer, and those questions are where the next quarter’s discovery work lives. Platform teams that can answer the CFO’s questions get to keep building. The rest get reorganized into something else by the next strategic review. Pick which one you want to be.