How much a developer really earns you: the truth about outstaff margin

«I was sure I made 40% on each developer. The first time we broke it down per person it came out at 11%. The gap was bench time I simply never thought of as a cost.»

Those are the words of an owner running a 14-engineer outstaff studio. The story is familiar to almost anyone who rents out a team by the hour: the client rate minus the developer's salary looks like profit. In reality half the company hides between those two numbers — and until you split costs per person, you manage revenue, not margin.

Why «rate minus salary» lies

Take a typical mid-level engineer. You bill the client $35 an hour; the developer costs about $3,000 a month after taxes. In the owner's head that's $35 against roughly $20 — a margin near 43%. It looks great, and it's exactly this number people lean on when deciding to hire more, give a discount or raise a salary.

The problem is that a developer does not deliver 160 billable hours a month. Between projects they sit on the bench. Onboarding a new client eats a week while the person gets into someone else's code and processes. Add meetings, code review, learning, sick days, holidays. Real utilization — the share of hours the client actually pays for — even in healthy studios rarely exceeds 75%. And every non-billable percent you fund out of your own pocket.

The breakdown for one person

Let's count honestly, with the same numbers.

43% on paper became 12% in real life. And that is still the good scenario. Let utilization drop to 60% because of one empty month, and the same developer goes negative — even though you pay the salary all the same.

Let's count over a full year

The monthly figure is misleading because the bench is uneven. Take the same mid-level engineer over a year. For ten months they run at 80%, one month at 40% (a project ended, the next hadn't started), and one week in total goes to sick days and learning. Over the year the client paid for roughly 1,250 hours instead of the theoretical 1,920. Revenue: about $43,750. Salary with taxes: $36,000. Overhead per person: $8,400. Annual profit from the developer: about −$650. The same engineer who «gives 43% margin» ended the year slightly negative — all because of one empty month and a few non-billable weeks smeared across the year.

«The bench shows up on no invoice, so nobody sees it. And it eats more than any discount to a client.»

Three costs everyone underestimates

First, the bench. The time between projects is paid by you, not the client. One empty week a month is minus 25% of revenue per person at the same salary. In a 14-person studio even a 10% average bench is like keeping a person and a half who bring in nothing.

Second, non-billable hours inside a project. Daily standups, client syncs, reviews, research, rework after requirements change. The client pays for 6 hours while 8 are occupied. Those two hours a day are your cost too, just invisible.

Third, management overhead. Every five or six engineers need a project manager, and recruiting or replacing a person costs about a month of their salary, plus the months until the newcomer reaches full speed. That money is tied to no single invoice, which makes it easy to miss — until you count profit per person after overhead.

What it looks like in real life

You hear the problem in typical phrases inside the studio. «We have lots of projects but little profit.» «We grew to 20 people, but the owner earns like it's 12.» «A client dropped off — we'll manage, we'll put the person on an internal project» (that is, on full bench at your expense). «Let's give this client a 10% discount, they're big» — while the margin on that account was already 12%, and the discount makes it loss-making.

All of these are symptoms of one thing: the studio counts the rate-minus-salary gap and never counts profit per person after bench and overhead. Revenue is large, and the owner wonders where the profit goes.

How to see the margin on each developer

To manage this you need to see revenue and costs per person or per project, not in one bucket. In Finmap you set up projects and directions, post client revenue and the direct cost of the person doing the work — and you see gross margin per engineer and for the studio overall. The bench stops being invisible: an empty month shows up in the report immediately, not six months later as a vague «profit dipped somehow». You also see which client brings a normal margin and which merely loads people almost for free.

Related — how management accounting differs from bookkeeping in IT and how to measure team utilization.

What to do about it

• Set a target utilization and watch it weekly, not once a quarter. An empty week caught in time can still be closed with a sale.
• Price the bench in: the rate must cover not only busy hours but the inevitable empty ones. If target utilization is 75%, the rate is built from that, not from 100%.
• Measure profit per person after overhead, not the gross rate-minus-salary gap. Only the first number tells the truth.
• Look at margin by client: a big client with a discount often brings less than a small one at full rate.
• Plan replacements and hiring from the load, not «just in case». Every «growth» person without a project is pure bench at your expense.

Outstaff feels like a simple business until you start counting per person. Once you do, it becomes clear who actually earns, who sits on the bench, and where margin leaks through non-billable hours. And then decisions about hiring, discounts or a new project are made on numbers, not on a feeling that «there are lots of people, so things must be fine».

Money Doesn't Disappear. You Just Don't See It.

Try Finmap free for 14 days and see the margin on every developer and project this month — with no manual spreadsheet stitching.