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. Here's the model, the objections, and how to answer them.
Platform teams are a cost center right up until someone makes the value legible. The number doesn't need to be precise — precision is impossible 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, not an 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 is already costing instead. Take fully-loaded FTE cost — salary, benefits, overhead, typically 1.25–1.5x base salary — multiply by the estimated share of time lost to friction, sourced from actual interviews rather than guesswork, and that's the current annual cost of the problem before a single dollar of platform investment is spent. This is 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 actually ask for
- Payback period — months until cumulative savings exceed the investment. This is the number most sponsors ask for first, and the one to lead the executive summary with.
- 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 only 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, the faster lead time turning into competitive advantage — all real, all arguable. A number built only on toil removed is the one that survives scrutiny, because it doesn't require anyone to accept a projection about markets or morale. If the platform pays for itself on toil alone, everything else is upside you get to mention after the case is already approved, not upside you needed to make the case work in the first place.
The three objections, and how to actually answer them
- "These numbers are too optimistic." Show the sensitivity range, not a single point estimate. A conservative→optimistic band demonstrates you've already accounted for the objection instead of getting defensive about it.
- "We don't have budget for this." Reframe as the cost of inaction — the org is already paying the friction cost today, it's just not itemized on a line anyone looks at. Declining the platform doesn't remove the cost, it just keeps it unmeasured.
- "We tried a platform team before and it didn't work." This is almost never a pricing objection — it's a team-topologies one. Usually the previous attempt turned into a ticket queue (platform-as-side-project, or mandated adoption without a working golden path) rather than a genuine 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 single biggest risk if nothing changes. Everything else — detailed assumptions, sensitivity analysis, the full driver breakdown — belongs in an appendix for whoever wants to dig in, not in the version that has to win the room in the first five minutes.