← FinOpsAid blog
What does one developer cost us? GitHub unit economics that survive a budget review
Total spend divided by headcount is the ratio everyone reaches for, and it's the one that answers nothing. Here's how to build a GitHub cost-per-developer figure with a denominator that can actually move — and how to keep it from being mistaken for a performance metric.
Sooner or later the question arrives in this exact shape: what does a developer cost us on GitHub? It sounds like a request for one number, so most people produce one — last month's bill divided by engineering headcount — and everyone nods. Then someone hires twelve people, the ratio drops, and nobody can say whether that's good news.
The problem isn't that the question is unfair. It's that total ÷ headcount is a ratio where both halves are wrong. Fix the denominator and the numerator and you get a unit economic that behaves like a real operating metric: it moves when you do something, and it holds up when someone interrogates it.
Why total ÷ headcount answers nothing
A ratio is only useful if you can act on it. This one fails that test twice over.
The denominator includes people who never touch the surfaces you're paying for. Your data analysts, your contractors, the twenty engineers on a team that hasn't merged to a private repo in a quarter — all of them dilute the figure without changing a cent of spend. Hire into a non-engineering function and your "cost per developer" improves. That's not efficiency, that's arithmetic.
The numerator has the opposite problem. It blends genuinely fixed cost (seats you've committed to) with genuinely variable cost (Actions minutes, Codespaces core-hours, AI usage) into one lump. A month where CI ran hot and a month where you assigned forty new seats look identical in the total and demand completely different responses.
Both halves of the ratio are wrong by default. The higher figure isn't the worse one — it's the honest one, and the only one that responds to a decision. Dollar values are illustrative.
Pick a denominator that can move
The fix is to count active developers, not employed ones. An active developer is someone who did something on the platform in the period: pushed a commit, opened or reviewed a pull request, ran a workflow, used an assigned Copilot seat.
That definition does real work. The gap between headcount and active developers is itself a finding — it's usually where dormant seats live, and a dormant seat is a security question as much as a cost one. More importantly, an active-developer denominator responds to management. Reclaim idle seats and the number moves. Onboard a team properly and it moves. Hire a recruiter and it doesn't move at all, which is correct.
Write the definition down and keep it stable. A unit economic that quietly changes its own denominator between quarters is worse than no unit economic, because it looks like a trend.
The numerator is mostly modeled, and you have to say so
Here is the part that gets skipped. GitHub bills your organization, not your developers. For several of its most expensive surfaces there is no per-person line item at all, so any per-developer dollar figure you produce is an allocation — a modeled number, not a billed one.
Some of it is clean. A Copilot seat is assigned to a named person at a known price, so that portion is close to actual. Most of the rest isn't. Actions minutes attach to a workflow and a repository, and getting from there to a person means apportioning by commits, by team ownership, or by some rule you chose. Storage is worse. AI credits are worse still, because credits are a usage signal rather than a billed total and treating them as dollars is how a dashboard ends up confidently wrong.
None of that makes the exercise pointless. It makes labelling mandatory. Every per-developer figure should carry its basis — actual where it's genuinely billed per person, modeled where you allocated it — and the allocation rule should be one sentence long and written down. A modeled number you can explain survives a budget review. A precise-looking number you can't reproduce does not.
The ratios actually worth tracking
One number won't cover it. A small set will:
- Total GitHub cost per active developer. The headline. Watch the trend, not the level.
- Copilot cost per active Copilot user. Different denominator on purpose — it isolates seat hygiene from everything else, and it's the figure that makes the Copilot ROI conversation concrete.
- Variable cost per active developer. Actions, Codespaces, storage, AI usage, with the seat cost stripped out. This is the half that reacts to engineering behaviour within the month.
- Cost per active developer, by team. The org-level figure hides everything interesting. Attribution is where the decisions live, which is the whole argument for showback before chargeback.
What this metric is not
It is not a productivity measure, and the moment it gets used as one it stops working.
The failure mode is predictable. Someone sorts the developer list by allocated cost, and the expensive names are the ones running the big integration suites, maintaining the monorepo, or doing the CI work everyone else depends on. Optimise against that ranking and you'll punish exactly the people carrying the platform. Cost per developer is a denominator for a spend conversation, not a scoreboard, and it belongs in aggregate — org, team, cohort — not next to individual names in a performance review.
Say that out loud when you present it. It's the difference between a metric engineering trusts and one it learns to game.
A monthly ritual
- Recompute active developers first. Then the ratio. Never the other way round.
- Split fixed from variable. A seat problem and a CI problem look the same in the total and need opposite fixes.
- Check the basis flags. Know what share of your per-developer dollars is modeled before anyone asks.
- Compare against yourself, then against peers. Your own trend is the honest baseline; a cohort comparison tells you whether the level is defensible.
- Report the ratio next to the total. Spend up 20% while cost per active developer falls 8% is a growth story. Spend flat while the ratio climbs is a warning.
Get in the habit and the annual "what does a developer cost us" ambush turns into a number you already have, already trust, and can already explain.
Keeping that set current is what FinOpsAid's unit-economics and Developers views are built for: active-developer counts recomputed from nightly snapshots, per-person dollars tagged actual or modeled so you always know which you're quoting, and every figure stamped with the sync it came from and reconciled back to the billed invoice.
Frequently asked questions
Why is total spend divided by headcount a bad metric?
Because the denominator cannot move in response to anything you do. Headcount changes for reasons unrelated to cost management, so the ratio drifts without telling you whether anything improved. Divide by active developers instead — a denominator that responds to adoption work.
What is a good cost per active developer for GitHub?
There is no universal figure, and any vendor quoting one is guessing. What matters is your own trend and, where a genuine cohort exists, your position within it. A rising cost per developer against flat total spend means fewer people are using the tool, which is an adoption problem rather than a price one.
Is cost per developer a performance metric?
No, and it breaks the moment it is used as one. It is a unit-economics figure for judging whether tooling spend scales sensibly with the team. Attach it to a person's review and you will get behaviour that optimises the metric rather than the work.
Want your real cost per active developer without building the allocation pipeline yourself? Connect your GitHub org — read-only and free during beta — or explore the demo dashboard first.