Platform engineering cost per developer served: the formula and our model
Total annual platform spend divided by product engineers served. There is no published market benchmark for it, so here is the formula, our model's output at each ratio and org size, and what moves the number.
The formula
(platform team loaded cost + tooling + platform cloud + overhead) / product engineers served
Product engineers served is the count of engineers who are using or would use the platform. Do not include platform engineers themselves in the denominator. Do not include contractors unless they are doing product work against the platform.
Our model, by ratio and org size
Cost per developer served at each platform-to-product ratio, with the $190k blended loaded rate, standard tooling, managed cloud and overhead included. These are outputs of our planning model, not survey data; the inputs are on /methodology and you can change each one on /calculator.
| Ratio | 100 devs | 250 devs | 500 devs |
|---|---|---|---|
| 1:8 | $34,255 | $33,518 | $32,981 |
| 1:10 | $27,700 | $27,400 | $27,300 |
| 1:12 | $25,515 | $23,904 | $23,804 |
| 1:15 | $21,145 | $20,408 | $20,308 |
| 1:20 | $16,775 | $16,912 | $16,375 |
The org-size pages use the team sizes set out on each page, including leadership headcount from 250 engineers up: 50, 100, 250, 500 and 1,000 developers. Our general planning band is 1:8 to 1:12; see /team-structure for why it is a heuristic, not a survey finding.
What moves the number
- Platform-to-product ratio. The biggest lever by far, because salary is the largest line. The table above shows how far it moves the figure.
- Seniority mix of the platform team. A team weighted toward staff and principal engineers carries a higher loaded rate than one weighted toward mid-level; change the loaded-cost input on the calculator to see the effect.
- Commercial tooling tier. Tooling is costed per product engineer, so moving from lean to enterprise tier flows straight through to cost per developer served.
- Regulated vs unregulated stack. Compliance, audit and data-residency work need more platform capacity per engineer, which shows up as a tighter ratio.
- Build versus buy. Heavy-build organisations look cheaper on tooling and more expensive on headcount; heavy-buy organisations the opposite.
Reading your own number
A low figure can mean a mature self-service platform or an under-invested one whose cost is showing up elsewhere as slow delivery; adoption rate and developer-reported friction tell the two apart. A high figure can mean a small organisation carrying a minimum viable team, an organisation building ahead of growth, or a team doing product work. Track your own number year over year: whether it falls as the organisation grows says more than any single-year comparison.
Benchmarking pitfalls
- Inconsistent "developer served" definitions. Some companies include contractors, some exclude them. Some include data, ML and mobile engineering; some count only backend. Compare like with like.
- Platform cloud not always counted. Organisations running on-premise infrastructure often leave the platform-attributable infrastructure out of the numerator, understating cost.
- International salary bands. A platform team with offshore members has a lower blended loaded cost, which pulls the per-developer number down without reflecting efficiency.
How to use it
For finance justification, cost per developer served is the single number that makes the platform investment legible to non-engineering leaders. For trend tracking, it shows whether the platform is scaling economically. Do not use it for compensation decisions or team-level performance reviews: it is an organisational metric, not an individual one.