Platform Engineering business case papers fail in review far more often than the discipline deserves. The engineering argument is nearly always sound — every team builds its own pipeline, nobody can find the runbook, and a new starter waits a month for their first production change — but the paper that reaches the finance committee counts a portal licence, forgets the four people who will run it forever, and never says where the recovered developer hours went.
This guide gives you the working rather than the argument. It sets out the costed investment schedule a reviewer expects, the four benefit streams that carry almost every case, how to price developer toil without double counting, the payback and net present value maths finance asks for, and a fully worked two-year model for a 120-engineer company. It sits alongside our DevOps consulting and cloud architecture practice.
It is written for mid-sized companies specifically, because the arithmetic that works at 800 engineers does not survive at 120. Platform engineering treats the internal delivery toolchain as a product with users, a roadmap and an owner, rather than as a pile of shared scripts nobody maintains. If you have not yet measured your delivery baseline, our DevOps maturity assessment guide is the right starting point, because a return calculation without a measured starting position is just an opinion with decimal places attached.
Table of contents
- What a Platform Engineering business case must prove
- Build the Platform Engineering business case cost baseline
- The four benefit streams in a Platform Engineering business case
- The Platform Engineering business case formula
- How to price developer toil in a Platform Engineering business case
- Putting a number on failed changes, waste and onboarding
- Payback, NPV and sensitivity in a Platform Engineering business case
- A worked Platform Engineering business case for a 120-engineer company
- Does build or buy change the Platform Engineering business case?
- Platform Engineering business case benchmarks for mid-sized companies
- Mistakes that sink a Platform Engineering business case
- Phasing a Platform Engineering business case for early benefits
- Reporting the Platform Engineering business case after approval
- Frequently asked questions about the Platform Engineering business case
- References
What a Platform Engineering business case must prove
A Platform Engineering business case makes four claims, in order, and a reviewer tests each one separately. That the current way of working costs real money. That the platform removes a named portion of that cost. That the released capacity has somewhere specific to go. And that the number survives when the central assumption is halved.
It is a finance paper, not an architecture paper
The audience is a finance director and an executive sponsor, not a staff engineer. Every technical claim needs a monetary translation and an evidence source. Anything that cannot be translated belongs in an appendix rather than in the headline ratio, and a diagram of the control plane belongs nowhere near page one.
The three questions every reviewer asks
What would have happened anyway without this spend? Where does the released engineering capacity actually go, and who signs up to receive it? What happens to the answer if the central assumption is half as good as claimed? A Platform Engineering business case that answers all three in advance is approved far more often than one with a larger headline percentage.
Why “developer experience” is not a benefit
Developer experience is a leading indicator, not a line in a budget. Nobody banks a satisfaction score. The benefit is what the recovered hours produce: features shipped earlier, incidents avoided, environments switched off, audit evidence that no longer consumes a fortnight. A case that stops at survey results asks the finance function to finish the argument for you, and it usually declines.
What a credible case contains
Six artefacts: a costed baseline of current developer toil, an itemised investment schedule that includes the standing team, four quantified benefit streams with named owners, a two-year cash flow, payback and net present value figures, and a sensitivity table. Anything less is a preference dressed as a proposal.
Build the Platform Engineering business case cost baseline
Start a Platform Engineering business case with cost, not benefit. It is the half most teams understate, and an understated denominator collapses the moment a reviewer adds the missing lines back in. Mid-sized companies get this wrong in a particular way: they price the tooling and forget the team.
The platform team is the whole cost, not the tooling
An internal platform is a product, and products have standing engineering costs that never end. Somebody maintains the templates, reviews the pipelines, upgrades the provider versions and answers questions in a support channel. Four fully loaded engineers cost roughly six times the portal licence, and leaving them out of years two and three is the single most common structural error reviewers look for.
Tooling, licences and the portal
Count the developer portal, additional continuous integration capacity, secrets management, artefact storage, policy enforcement and the observability seats the platform itself consumes. Price year two at the contracted uplift rather than the introductory discount, because launch pricing is exactly why a model looks better in the deck than in the ledger eighteen months later.
Migration and golden path authoring
Writing the first golden path is cheap. Moving sixty existing services onto it is not. Every template, base image, deployment manifest and pipeline conversion consumes senior time, and the teams being migrated lose delivery capacity that week. Price those hours at the same rate you use on the benefit side, or your Platform Engineering business case values an hour spent differently from an hour saved.
Training, enablement and the dual-running period
Every engineer learning a new deployment workflow is delivery you did not get. Worse, the old path stays alive until the last service moves, so you fund both for a year. That overlap is real money and it belongs in the denominator of the Platform Engineering business case rather than in a footnote nobody reads.
| Cost line | What it must include | Year 1 | Year 2 | Where the figure comes from |
|---|---|---|---|---|
| Platform team | 3 platform engineers plus 1 platform product lead, fully loaded | £416,000 | £429,000 | HR cost-per-head, not base salary |
| Tooling and licences | Portal, pipeline capacity, secrets, policy, observability | £72,000 | £78,000 | Contract schedule at renewal pricing |
| Golden paths and migration | Template authoring, service conversion, runbook retirement | £168,000 | £56,000 | 3,000 then 1,000 hours at the blended rate |
| Training and enablement | Formal training, pairing, documentation, dual running | £34,000 | £14,000 | Hours at the same rate used for benefits |
| External enablement | Reference architecture, review, specialist help | £60,000 | £0 | Statement of work, plus contingency |
| Total investment | All of the above, one scope, one window | £750,000 | £577,000 | The denominator of the ratio |
The four benefit streams in a Platform Engineering business case
Almost every credible case draws from the same four streams. Naming them separately matters, because each one has a different owner, a different evidence source and a very different realisation risk. Blending them into a single “productivity” number is how a paper gets sent back for rework.
Developer time released from platform toil
Hours engineers stop losing to waiting, repetition, pipeline archaeology and access requests. This is always the largest stream and always the most contested, because released capacity only becomes money when somebody can show what it produced instead. Treat it as the stream that needs the most evidence, not the least.
Cloud and licence waste removed
Ephemeral environments, standard sizing defaults and automatic teardown stop you paying for idle non-production capacity, while consolidating three overlapping toolchains onto one removes duplicate seats. This stream is the easiest to evidence because the invoice already exists, and our Azure cost optimisation checklist covers the specific controls that produce it.
Failed changes and incident cost avoided
A reviewed, templated, automatically tested path to production cuts both the number of failed changes and the cost of each one. Incident records already exist, which makes this the stream auditors trust most and the one least likely to be argued down. It is also the stream that survives a sceptical reviewer intact.
Onboarding and compliance evidence
New starters reach their first production change in days rather than weeks, and policy-as-code turns audit evidence from a fortnight of screenshots into a query. Quantify the effort reliably and the risk reduction conservatively, because reviewers discount a probability-weighted loss far harder than a timesheet. Our cloud security posture assessment guide sets out the controls this stream depends on.
| Benefit stream | What you measure | How it converts to money | Evidence source | Realisation risk |
|---|---|---|---|---|
| Developer time released | Hours per engineer per week lost to platform toil | Hours × blended rate × realisation factor | Time study plus ticket and pipeline logs | High — needs a named destination |
| Cloud and licence waste | Idle non-production spend and duplicate seats | Direct reduction on the invoice | Billing console and licence register | Low — appears on the bill |
| Failed changes avoided | Change failure rate and remediation hours | Failures avoided × blended cost each | Incident and change records | Low — records already exist |
| Onboarding and compliance | Days to first production change, audit days | Days × rate, plus reduced remediation | HR records and audit timesheets | Medium — ramp value needs a haircut |
The Platform Engineering business case formula
The arithmetic is deliberately simple. All of the judgement sits in what you allow into each side of it, which is why reviewers spend their time on your assumptions rather than your spreadsheet.
The core calculation
Return equals net benefit divided by total investment, expressed as a percentage over a stated period. Net benefit is total benefit minus total investment. A Platform Engineering business case costing £1,327,000 across two years and returning £1,544,000 produces a net of £217,000 and a return of 16%. Always state the window in the same breath as the percentage, because a 16% two-year return and a 16% annual return are entirely different propositions.
Choosing the measurement window
Two years is the conventional default and, for platform work in a mid-sized company, it is usually the wrong one. Coverage ramps through the first eighteen months, so a two-year window pays the full team cost while collecting only partial benefit. Three years is the honest ask. Say so in the paper rather than letting a reviewer discover it.
Pricing a developer hour
Use the cost per head finance already recognises: salary, employer national insurance, pension, benefits, equipment and an allocated share of overhead. For a UK mid-market product engineer that commonly lands near £92,400 against a £70,000 base. Divide by productive hours — roughly 1,650 a year after holiday, sickness and training — and the blended rate is £56. Senior platform engineers are costed separately at £104,000.
Applying a realisation factor
Removing 17,388 hours of toil is not the same as banking £973,728. Some released time enters the roadmap, some absorbs into slack, and some funds the platform work itself. Sixty per cent is a defensible default, so the model claims £584,000 and survives questioning precisely because the haircut is visible rather than hidden inside an optimistic assumption.
How to price developer toil in a Platform Engineering business case
This is the stream that decides whether the paper is credible, so measure it properly. A Platform Engineering business case built on a guessed percentage of developer time is the easiest thing in the world for a finance director to reject.
Measure the week, not the mood
Run a two-week structured time study across a representative sample of teams, categorised by activity, and reconcile it against ticket queues, pipeline run logs and access request volumes. Three independent sources agreeing is evidence. A survey asking engineers how frustrated they feel is not, however accurate it turns out to be.
The baseline for a 120-engineer organisation
Seven hours per engineer per week is a common finding at this size: waiting on environments and access, debugging pipelines, repeating build and configuration work across services, hunting for documentation and owners, and answering compliance requests. Across 120 engineers and 46 working weeks that is 38,640 hours a year, or roughly £2.16 million of fully loaded capacity.
What the platform position looks like
A mature golden path does not remove all of that. It removes the repetition and most of the waiting, leaving the genuinely bespoke work behind. Forty-five per cent is a defensible planning figure at full coverage, which is 17,388 hours. Apply the realisation factor and the Platform Engineering business case claims £584,000 a year once coverage is complete.
The double counting trap
If a separate automation, cloud migration or Infrastructure as Code business case already claims provisioning hours, you cannot claim them again. Draw an explicit boundary in an appendix showing which activity belongs to which paper. Reviewers who have seen the same saving twice will look for it a third time, and finding it costs you the whole case.
Putting a number on failed changes, waste and onboarding
The three smaller streams are worth more attention than they usually get, because between them they carry 45% of the benefit and almost none of the argument. They are also the streams that hold up when a reviewer discounts everything else.
Change failure rate as a cost driver
Take the change volume and failure rate from your delivery records rather than from memory. A 120-engineer organisation shipping 820 production changes a year at a 22% failure rate is absorbing 180 failures. Price each one at the remediation hours plus a weighted share of customer impact, which commonly blends out near £2,150.
What a golden path actually changes
Templated pipelines, mandatory automated checks, consistent rollback and a single reviewed deployment route move failure rates into the low teens. Cutting 22% to 12% avoids 82 failures a year, worth £176,000. That figure is defensible because both inputs come from systems the finance team can inspect without asking an engineer.
Environment and licence waste
Non-production commonly runs at 32% of total cloud spend, and most of it idles overnight and at weekends. Ephemeral environments with automatic teardown and sane sizing defaults remove around a quarter of it, which on a £2.4 million bill is £192,000. Add £42,000 of consolidated licences and the stream is worth £234,000 a year.
Onboarding and audit effort
Time to first production change falling from 32 days to 11 is worth about £3,100 per hire after a conservative ramp discount, and 34 starts a year makes £105,400. Audit and customer security reviews drop from 46 evidence days to 17. Together, after realisation, the stream contributes £94,000 to the Platform Engineering business case at full coverage.
Payback, NPV and sensitivity in a Platform Engineering business case
Three numbers decide the outcome: when the cumulative position turns positive, what the cash flow is worth today, and how far the answer moves when the main assumption is wrong. A Platform Engineering business case missing any of the three reads as unfinished.
Simple payback period
Accumulate net cash flow month by month and read off the month it crosses zero. In the worked model, year one is £204,000 negative and year two runs £421,000 positive, or £35,083 a month, so the crossing happens at month 18. State it in months, because “under two years” is the phrasing reviewers have learned to distrust.
Net present value and the discount rate
Ask finance for the discount rate rather than choosing one; 10% is a common UK mid-market figure. Discounting the worked model gives a two-year net present value of £162,000 and a three-year figure of £530,000. The gap between those two numbers is the entire argument for the longer window, and it is worth showing explicitly.
Sensitivity analysis
Halve your central assumption and publish what happens. In this model the realisation factor and the toil reduction percentage multiply together, so cutting either one to two-thirds does identical damage — and a reviewer who cuts both has quartered your largest stream. Showing that you already know this is the difference between a challenged case and a rejected one.
Why the two-year window is the hard one
Only the base case pays back inside two years. Three of the four downside scenarios need a third year, which is not a flaw in the analysis but a property of platform investment: the team cost starts at full rate on day one while coverage arrives gradually. Say it plainly and ask for the window you actually need.
| Scenario | What changes | Two-year benefit | Two-year net | Payback |
|---|---|---|---|---|
| Base case | 45% toil reduction, 60% realisation | £1,544,000 | +£217,000 | Month 18 |
| Realisation cut | Realisation factor 40% instead of 60% | £1,261,000 | −£66,000 | Month 27 |
| Weaker toil reduction | 30% of toil removed instead of 45% | £1,261,000 | −£66,000 | Month 27 |
| Slow adoption | Coverage arrives six months late | £1,257,000 | −£70,000 | Month 26 |
| Cloud stream removed | Waste already owned by a separate programme | £1,216,000 | −£111,000 | Month 30 |
| Base case, three years | Same assumptions, one more year of full coverage | £2,632,000 | +£707,000 | Month 18 |
A worked Platform Engineering business case for a 120-engineer company
Numbers make the method concrete. This is a complete Platform Engineering business case for a UK company of 640 staff, and every figure traces back to a system somebody can open in front of you.
The starting position
Fourteen stream-aligned teams, 120 engineers, 60 services, £2.4 million of annual cloud spend and no shared delivery layer. Each team maintains its own pipeline. Change failure rate is 22%, a new engineer takes 32 days to reach their first production change, and seven hours per engineer per week disappear into platform toil.
The investment
Four fully loaded platform people at £416,000, tooling at £72,000, 3,000 hours of golden path authoring and migration at £168,000, £34,000 of training and £60,000 of external enablement gives a year one total of £750,000. Year two drops to £577,000 as migration completes but the standing team cost remains, which is the line most models quietly delete.
Year one benefits
Coverage reaches 55% of services by month twelve. The toil stream contributes £321,000, cloud and licence waste £117,000, avoided failures £70,000 and onboarding with compliance £38,000. Total year one benefit is £546,000 against £750,000 of cost, so the first year of the Platform Engineering business case is £204,000 negative, exactly as it should be.
Year two and the two-year result
Coverage reaches 90%. Benefits rise to £998,000 while costs fall to £577,000, producing £421,000 of net positive cash. Two-year totals are £1,544,000 of benefit against £1,327,000 of investment: a net of £217,000, a 16% return, payback at month 18 and a net present value of £162,000 at a 10% discount rate.
| Line | Year 1 | Year 2 | Two-year total |
|---|---|---|---|
| Developer time released | £321,000 | £526,000 | £847,000 |
| Cloud and licence waste | £117,000 | £211,000 | £328,000 |
| Failed changes avoided | £70,000 | £176,000 | £246,000 |
| Onboarding and compliance | £38,000 | £85,000 | £123,000 |
| Total benefit | £546,000 | £998,000 | £1,544,000 |
| Total investment | £750,000 | £577,000 | £1,327,000 |
| Net position | −£204,000 | +£421,000 | +£217,000 |
Does build or buy change the Platform Engineering business case?
Tooling choice moves the numbers less than most teams expect, because the standing team dominates the cost either way. It matters most for how quickly coverage arrives, and coverage speed is what the payback month is actually made of.
Self-assembled open source
Cheapest on licences, most expensive in engineering. You own the integration, the upgrades and the incident response for every component. For a mid-sized company this typically means one additional platform engineer permanently, which costs more than any portal subscription on the market.
Commercial developer portals
A licence fee in exchange for someone else maintaining the catalogue, templates and plugin surface. The value is coverage arriving three to six months sooner, and in a Platform Engineering business case built on ramp speed, six months of earlier coverage is usually worth several times the annual fee.
Managed platforms and hosted control planes
Highest recurring cost, lowest engineering commitment, and a real lock-in question to answer honestly in the risk section. They suit companies whose constraint is hiring rather than budget. Our Kubernetes versus serverless comparison covers how the underlying runtime choice interacts with this decision.
Do not let the tooling debate delay the paper
Write the Platform Engineering business case with a tooling range rather than a product name, and show the payback under each option. A three-month evaluation costs 120 engineers a quarter of their toil savings, which is far more than the difference between the two products being compared.
| Option | Annual licence | Platform team needed | Time to 50% coverage | Best when |
|---|---|---|---|---|
| Self-assembled open source | £0 to £18,000 | 5.0 FTE | 12 to 15 months | Strong existing platform skills in house |
| Commercial developer portal | £45,000 to £90,000 | 4.0 FTE | 8 to 10 months | Coverage speed drives the payback |
| Managed platform | £120,000 to £240,000 | 2.5 FTE | 6 to 9 months | Hiring, not budget, is the constraint |
Platform Engineering business case benchmarks for mid-sized companies
Benchmarks give a reviewer somewhere to stand. Use them to sanity-check your own figures rather than to replace them, because a borrowed number is the first thing an experienced finance director asks you to justify.
Platform team sizing ratios
One platform engineer per 25 to 35 developers is the working range, which puts a 120-engineer company at four people including the product lead. Below roughly 40 engineers a dedicated team rarely pays, and the honest recommendation is a part-time enabling role plus managed tooling instead.
Typical payback windows
Mid-sized companies commonly see payback between month 16 and month 30 depending on how fast coverage arrives. Anything under twelve months deserves a hard look at whether the standing team cost was included for the full period. Anything past 36 months usually means the organisation is too small for the model.
Delivery benchmarks worth citing
Gartner expects 80% of large software engineering organisations to run platform teams by 2026, up from 45% in 2022. Puppet’s research links high developer cognitive load to lead times around 40% longer. Both are useful context, and neither substitutes for your own measured baseline.
When the case is genuinely weak
Fewer than 40 engineers, a single product with one deployment path, or a team already six months from a major re-platforming: in all three the Platform Engineering business case is better deferred. Saying so protects your credibility for the proposal you bring next quarter, and reviewers remember which sponsors withdraw weak papers.
Mistakes that sink a Platform Engineering business case
Rejections cluster around four errors, and all four are visible in the paper before it is ever submitted. Reading your own draft looking for them is the cheapest review round you will ever run.
Counting the tooling and not the team
The portal is the smallest line in the schedule. A case that leads with licence cost tells a reviewer immediately that nobody has thought about who runs this in year three, and the question that follows is one you cannot answer in the meeting.
Claiming full realisation of released hours
Nothing kills a Platform Engineering business case faster than converting every saved hour into cash at the full rate. Apply the haircut yourself, show it, and name the destination for the remaining capacity. A visible discount buys more credibility than it costs in headline value.
Baselining against your worst quarter
Choosing the quarter with the outage, the audit and the failed migration inflates the benefit and invites a reviewer to ask what a normal period looked like. Use a rolling twelve months. It is lower, it is defensible, and it survives the second meeting.
Selling a portal instead of an outcome
Executives do not fund catalogues, templates or control planes. They fund shorter time to market, fewer customer-visible failures and lower cloud bills. Lead the Platform Engineering business case with the outcome, and keep the architecture where it belongs, which is in the appendix.
Phasing a Platform Engineering business case for early benefits
Sequencing decides the payback month, and the payback month decides the approval. Two Platform Engineering business case papers with identical totals can land two quarters apart on cumulative position purely because of the order of work.
Start with the highest-volume path
Whichever service shape your teams create most often is the first golden path. Volume is what turns a template into a saving. Building the perfect path for the one service nobody deploys is the most common way to spend six months and show nothing at the first review.
Take the environment waste early
Ephemeral environments and automatic teardown deliver invoice-visible savings within a quarter and need no behaviour change from developers. Putting that stream first gives the Platform Engineering business case a hard, auditable number at the three-month mark, which buys patience for the slower streams behind it.
Migrate by template, not by rewrite
Move services onto the path as they are, then improve them. A migration that requires each team to refactor first stalls, because it competes with the roadmap. Our DevOps ROI guide covers how to sequence this without stopping delivery.
Leave the hardest services until coverage pays
The three legacy services with bespoke deployment needs will consume a quarter of your migration budget for a twentieth of the benefit. Schedule them last, or exclude them explicitly and say why. Reviewers respect a named exclusion far more than an optimistic total that quietly assumes everything moves.
Reporting the Platform Engineering business case after approval
Approval is the start of the measurement obligation, not the end of it. The teams that get funded again are the ones that reported honestly on the last thing they were funded for.
Set the measurement contract up front
Agree before approval which five measures will be reported, from which systems, at what frequency and to whom. Retro-fitting measurement to a Platform Engineering business case six months in produces numbers nobody trusts, and the argument about methodology consumes the meeting you needed for the decision.
The monthly pack
One page: service coverage against plan, hours per engineer per week lost to toil, change failure rate, non-production cloud spend, and benefit actual against forecast by stream. Pull it from the pipeline and billing systems directly, which our data analytics practice can automate in a fortnight.
Quarterly re-forecasting
Re-forecast every quarter against the same model structure. Change the inputs, never the method, or the comparison stops meaning anything. If a stream underperforms by more than 20% for two quarters running, revise it down publicly — credibility built by an honest downgrade pays for itself at the next funding round.
When to stop reporting
Stop programme-level reporting once the platform is business as usual and its measures have moved into normal service reporting, typically after ten quarters. Continuing past that point turns a decision tool into administrative overhead, and the operational metrics survive perfectly well on their own merit.
Frequently asked questions about the Platform Engineering business case
How many engineers do we need before a platform team pays?
Around 40 is the practical floor, and 60 to 80 is where a dedicated team clearly pays for itself. Below that the fixed cost of the standing team overwhelms the benefit, and the better answer is managed tooling with a part-time enabling role, reviewed again in a year.
How long before the investment turns positive?
Expect the cumulative position to cross zero between month 16 and month 30 for a mid-sized company. Year one is always negative. Any model showing a positive first year deserves a careful look at whether the platform team was costed for all twelve months rather than from the month they were hired.
Can we build the case without historical data?
Partly. Pipeline logs, ticket queues and billing consoles will give you change volumes, failure rates and idle capacity within a fortnight even with no prior reporting. The toil baseline needs a two-week time study, so if that is genuinely unavailable, build the Platform Engineering business case on the other three streams and note the omission.
Should we count developer satisfaction?
Report it, never bank it. Retention is the exception: if attrition among engineers is measurably above your sector average, a modelled reduction of one or two leavers a year at full replacement cost is a legitimate and separately evidenced line, provided you do not also claim their recovered hours.
What if we are already running Infrastructure as Code?
Then a large part of the provisioning saving is already booked, and claiming it again will be spotted. Rebase the toil measurement on the position after automation, and the Platform Engineering business case narrows to the developer-facing layer: templates, catalogue, self-service and golden paths.
