Building the business case for a platform without hand-waving
An ROI number only survives finance review if every input traces to a fully-loaded cost or a measured friction. The model, the objections, and how to answer them.
Platform teams are a cost center until someone makes the value legible. The number doesn't need to be precise, and it can't be for an investment whose biggest returns are avoided incidents and hours nobody has to spend waiting. It needs to be defensible: every input traceable to a fully-loaded cost, a measured friction or a cited benchmark, with no aspirational multiplier picked because it made the total look good.
Start from cost, not from benefit
The instinct is to lead with what the platform will deliver. Lead with what the absence of the platform already costs. Take fully-loaded FTE cost (salary, benefits, overhead, typically 1.25–1.5x base salary) and multiply by the estimated share of time lost to friction, taken from interviews rather than guesswork. That gives the current annual cost of the problem before a single dollar of platform investment is spent. It's the same three-line model behind the ROI calculator: hours lost, converted to a fully-loaded dollar cost, compared against the investment.
hours saved = developers × toil h/week × working weeks × reduction%
value = hours saved × (loaded cost ÷ working hours)
net = value − platform investment
Three numbers a sponsor will ask for
- Payback period: months until cumulative savings exceed the investment. Most sponsors ask for this first, so lead the executive summary with it.
- NPV: for multi-year platform investments, discount future savings so the case is comparable to any other capital project competing for the same budget.
- TCO: include the ongoing cost of running the platform (infrastructure, managed services retainer) so year two doesn't look artificially cheap. A model that shows build cost and skips run cost gets caught in the first finance review, and it should.
Why conservative wins
Skip the revenue upside, the retention effect, and faster lead time turning into competitive advantage. They're real, but every one of them is arguable. A number built only on toil removed survives scrutiny, because nobody has to accept a projection about markets or morale. If the platform pays for itself on toil alone, everything else is upside you can mention after the case is approved, instead of upside the case depends on.
The three objections, and how to answer them
- "These numbers are too optimistic." Show the sensitivity range instead of a single point estimate. A conservative-to-optimistic band shows you've already accounted for the objection, so you don't have to get defensive about it.
- "We don't have budget for this." Reframe as the cost of inaction. The org already pays the friction cost today, it just isn't itemized on a line anyone looks at. Declining the platform doesn't remove that cost, it just keeps it unmeasured.
- "We tried a platform team before and it didn't work." This is almost always a team-topologies objection, not a pricing one. Usually the previous attempt turned into a ticket queue (platform-as-side-project, or mandated adoption without a working golden path) instead of a self-service capability. Answer that failure mode directly instead of re-pitching the same number louder.
The one-page version
Executives don't read the model. They read one page: current cost, projected savings, payback period, and the biggest risk if nothing changes. Detailed assumptions, sensitivity analysis and the full driver breakdown belong in an appendix for whoever wants to dig in, not in the version that has to win the room in the first five minutes.