What an Unfilled Developer Position Really Costs Per Month
The number nobody puts on the vacancy
When a developer role sits open, most companies track exactly one number: the salary they are not paying. Finance treats it as savings. Engineering treats it as a staffing problem to be solved eventually. Neither view captures the cost of vacant developer position in the way it actually shows up in the business, which is delayed releases, tired teammates picking up the slack, and deals that slip a quarter because a feature was not ready.
Germany is short on developers to fill these roles in the first place. Bitkom's 2026 survey put the number of unfilled IT positions in the country at around 79,000, and most companies carrying one of those open roles are not treating the gap as an emergency, because nobody has attached a monthly figure to it. Once you do, the urgency changes.
The cost of vacant developer position starts with what the salary line hides
Say the role pays 95,000 euros a year, fully loaded with benefits and employer contributions. A finance team looking only at that line sees the vacancy as neutral at worst, a small saving at best. But the salary was never the whole cost of employing that person. It was the price of a set of outcomes: features shipped, bugs fixed, code reviewed, systems kept patched and running. None of those outcomes disappear when the role is empty. They either do not happen, or someone else does them on top of their own job.
That is the part the spreadsheet misses. The unfilled seat does not remove work from the team's plate. It redistributes it, badly, onto people who were already at capacity. A manager who only watches the salary budget will see a vacancy as a quiet win for a few months, right up until the team's output starts to show the strain and nobody can point to why.
Where the money actually goes
Four things happen inside a team carrying a vacancy, and each one has a price tag if you look for it.
Features slip. Whatever that developer would have shipped gets picked up by someone else, deprioritized, or dropped from the roadmap entirely. If the vacancy affects a customer-facing feature tied to a renewal or a new contract, the delay is not an engineering inconvenience, it is a revenue event.
The remaining team works overtime to cover the gap. This shows up as paid overtime in some companies and as unpaid extra hours and rising burnout risk in others. Either way it has a cost, and the second form is more expensive long term because it increases the odds that another person on the team leaves, which reopens the entire problem with a second vacancy on top of the first.
Maintenance work gets postponed. Dependency updates, security patches, and the unglamorous cleanup that keeps a codebase healthy are the first things a stretched team drops, because they rarely have a hard deadline the way a client deliverable does. Postponing them is not free. Every month a security patch waits is a month of exposure, and the fix does not get cheaper by waiting. This is also how technical debt quietly accumulates during a hiring gap: nobody decided to skip the cleanup work, it just kept losing to whatever was on fire that week.
Sales and product commitments quietly slip. A roadmap item a sales team has been promising to a prospect moves back a sprint, then two. Nobody frames this as the cost of the vacancy because the connection is rarely drawn out loud, but it is the same root cause wearing a different department's clothes.
A formula you can fill in this afternoon
You do not need a consultant to put a rough number on this. Take the developer's fully loaded annual cost and divide by twelve to get what the role would have cost per month if filled. Call that A.
Estimate the overtime or contractor hours the remaining team is spending to cover the gap, multiplied by their hourly rate. Call that B.
Estimate the monthly revenue impact of the single most important delayed feature or deal, even roughly. A delayed enterprise contract worth 40,000 euros in annual value that slips by one month is a 3,300 euro monthly cost while it waits. Call that C.
A vacancy that would have cost 8,000 euros a month in salary can easily run 15,000 to 25,000 euros a month once B and C are added, and that is before counting the security and maintenance debt building up in the background, which tends to surface as a much larger bill later rather than a monthly one.
Run this for your own numbers and the conversation with finance changes shape. The vacancy stops looking like a saving and starts looking like an unbudgeted monthly expense that happens to be invisible on the profit and loss statement. It also gives you a number to compare against the cost of speeding up the search itself, whether that means a recruiter fee, a referral bonus, or a wider salary band. Most of those options are cheaper than another month of B and C.
It is worth doing this exercise even for a role you expect to fill quickly. A search that looks like it will take six weeks routinely stretches to twelve once you account for interview scheduling, notice periods, and a candidate who turns down the offer after the first two rounds. Every one of those weeks is another week at your monthly figure, not at zero.
What three months of this looks like
The math above is monthly, but vacancies rarely close inside thirty days. Bitkom's figures suggest the average German company measures its open technical roles in months, not weeks, and a senior developer search realistically takes twelve to twenty weeks from first job posting to signed contract, longer for specialized custom software development roles where the candidate pool is smaller.
Multiply your monthly figure by three or four and the number most companies are quietly absorbing runs into six figures. That is money spent on overtime, delayed revenue, and deferred maintenance risk, none of which appears as a line item anyone reviews in a budget meeting, because it is spread across payroll, sales forecasts, and a maintenance backlog that only becomes visible when something breaks.
The cheaper way to bridge the gap
A vacancy has exactly two real solutions: fill the permanent role faster, or cover the gap with outside capacity while the search runs. Most companies only pursue the first one, which means the clock keeps running on all four costs above for the entire length of the search.
Bringing in an experienced developer or a small team on a temporary basis costs money too, but it is a cost you can plan for and scope, unlike overtime burnout or a slipped contract. It keeps the roadmap moving, takes the maintenance backlog off the remaining team's plate, and buys the hiring process time to find the right permanent hire instead of a rushed one. For a team already stretched thin, that trade is usually the cheaper option once you compare it against the monthly figure from the formula above, not against the empty salary line.
If you are carrying an open developer role right now and want a second opinion on what it is actually costing you, or want to talk through bridging the gap with outside capacity while you search, reach out at hello@wolf-tech.io. You can see more about how we work at wolf-tech.io.