A platform group of 9 engineers costs roughly $2.2M a year fully loaded. Its business case says it saves 300 product engineers 25 minutes a day. Finance does not believe the saving. Roughly what is the defensible number, and what does it rule in or out?

The assumptions, stated

Four numbers carry the whole estimate, and three of them are soft.

• 300 engineers, 25 minutes saved per engineer per working day. Self-reported, and almost never measured against a before-state.
• About 230 working days a year once holiday, leave and training come out.
• Fully loaded cost per engineer of roughly \(200k–\)300k a year for a US-based team in 2026, which is the number finance will use, not salary.
• A realisation factor: the share of recovered minutes that turns into output the business values.

The arithmetic, shown

300 × 25 minutes = 7,500 minutes a day = 125 engineer-hours a day. Over 230 days that is about 28,750 hours, which at a 2,000-hour engineer-year is roughly 14 engineer-years of capacity.

At \(200k–\)300k loaded, 14 engineer-years is \(2.8M–\)4.2M of gross recovered capacity against a $2.2M platform. On that reading the platform pays back 1.3× to 1.9×.

Then apply the realisation factor. Recovered minutes arrive in fragments of two to five minutes, scattered through the day, in whatever part of the system each engineer happens to own. Fragments do not aggregate into shipped features, and the recovered time lands on teams that may not be the constraint. A defensible factor is 30% to 50%, giving \(0.85M–\)2.1M of realised value. The honest conclusion: the time saving alone does not clearly clear the bill.

Which assumption dominates the error

Not the headcount and not the loaded cost, both of which are known to within 20%. The 25 minutes and the realisation factor together span a factor of five, so the output range is $0.85M to $4.2M. Narrowing the 25 minutes costs little: instrument pipeline duration, provisioning lead time and the number of tickets, and compare two quarters. Narrowing the realisation factor is close to impossible, which is the real finding.

What the number rules in or out

Ruled out: funding a platform on recovered minutes. Any case whose break-even needs a realisation factor above 50% is a case that dies in the first bad budget cycle, because the reviewer only has to dispute one unmeasurable multiplier.

Ruled in: the avoided-alternative argument, which is arithmetic nobody disputes. If 40 teams each ran their own deploy path, secret handling and environment tooling at roughly 0.3–0.5 of an engineer, that is 12 to 20 engineers of duplicated work against 9, and it is visible in the repositories of any company that did not centralise. Add two measured numbers the platform owns outright: p50 and p90 lead time from merge to production, and time for a new hire's first production change (weeks before, days after).

When this is the wrong answer

If the organisation has fewer than roughly 60 engineers, the duplication argument has no mass. Three teams solving a problem three times is cheaper than nine engineers solving it once, and the estimate above inverts: a platform group of 9 would be 15% of engineering spent on internal infrastructure. Below that size the defensible funding is one or two engineers on one paved pipeline, justified by lead time rather than by any savings model.

Common weak answers

• "We saved 4,000 engineer-hours." Hours are not fungible and the reviewer knows it. Convert, discount, and say which assumption you cannot defend.
• "Developer experience is strategic." True and unfundable. The budget conversation needs the counterfactual cost of the alternative, in engineers.
• Quoting the gross number with no range. A single-point estimate on a five-fold uncertainty reads as a sales pitch and loses the room.