Skip to main content

Tools — for hiring teams

What is this vacancy actually costing you?

A transparent way to compare hiring now, waiting, running the search internally or bringing in specialist support. Your numbers stay in your browser — nothing is sent to us, and there is no form to complete before you see the result.

1. The role

NI, pension, benefits — your figure, not ours.

2. How long it stays open

Your expectation, based on your own hiring history. We do not substitute a market average.

3. Optional — your impact estimates

Leave any of these at zero. Nothing is assumed on your behalf.

4. Optional — recruitment support

Enter a real quote, or model a percentage. Any percentage here is your scenario, not a Humand rate card.

Your result

Based only on the assumptions you entered, over 12 weeks (about 2.8 months).

Pay and on-costs not spent while vacant
£16,154
Internal hiring effort
£0
Delivery / revenue impact you estimated
£0
Delayed project or missed milestone
£0
Gross cost of delay
£0
Net cost of delay (gross, less pay not spent)
-£16,154
Recruitment support cost in your scenario
£0
That support costs more than the delay by
£16,154

If it stays open longer

At your assumptions, each additional day changes the net position by £192 in your favour.

Net cost of delay with additional time unfilled
Extra timeAddedNet total
+30 days-£5,769-£21,923
+60 days-£11,538-£27,692
+90 days-£17,308-£33,462

These figures are arithmetic on the numbers you entered. They are not a valuation, a forecast or advice.

Methodology

How the calculation works

Every figure comes from you. There is no universal multiplier in this tool — no "a vacancy costs a fixed share of salary", no assumed time to hire, no industry benchmark presented as fact. Where we do not have a defensible number, we ask you for yours.

Weekly run rate = annual salary x (1 + on-costs %) ÷ 52

Weekly run rate (contract) = day rate x days per week

Pay not spent = weekly run rate x weeks unfilled

Delivery impact = your monthly impact x (weeks ÷ 4.33)

Internal hiring effort = hours x loaded cost per hour

Gross cost of delay = delivery impact + internal effort + project delay

Net cost of delay = gross cost of delay − pay not spent

Net vs support = net cost of delay − recruitment support cost

Why does an unfilled role sometimes look like a saving?

Because it can be, on paper. While a role is vacant you are not paying for it, and if the work genuinely waits without commercial consequence the arithmetic will say so. The tool separates the pay you are not spending from the value you are not getting, so you can see which one is larger rather than blending them into a single headline.

What counts as delivery or productivity impact?

Whatever you can defend to your CFO: revenue that slips, a launch that moves, a support burden carried by the rest of the team, contractor cover, overtime, or a customer commitment at risk. If you cannot put a number on it, leave it at zero — the result stays honest and simply excludes it.

How should we estimate internal hiring effort?

Count the hours your own people spend: sifting, screening calls, interview panels, scheduling, debriefs and offer conversations. Multiply by a loaded hourly cost, not a bare salary rate. For engineering panels this is usually the largest hidden line.

When is paying for recruitment support economically rational?

When the support cost is less than the net cost of the additional delay you would otherwise carry, and when the support genuinely shortens that delay. Both halves matter. The sensitivity table exists for exactly this: if another 30, 60 or 90 days is affordable, the case for support is weaker; if it is not, the comparison usually answers itself.

Does this apply outside deep tech?

Yes. It is written for technology hiring broadly — software, data and AI, cloud and infrastructure, hardware and electronics, product, quality and technology leadership. The model does not care about the sector; only your numbers do.

What happens to the numbers I enter?

Nothing leaves your browser. The figures are not saved, not put in the page address, not sent to us and not included in any analytics. Close the tab and they are gone.

Are any of the pre-filled values a benchmark?

No. They are placeholders so the form is usable on first load, and every one is editable. Any example figure on this page is an example only.

A worked example (hypothetical)

Invented numbers, for illustration. They are not a Humand benchmark, not an average, and not a claim about your market — they are here so you can see which way the arithmetic runs before you put your own figures in.

Assumed salary
£75,000 + 20% on-costs
Assumed time unfilled
12 weeks
Assumed monthly delivery impact
£15,000
Assumed internal hiring effort
40 hours at £60/hour
Assumed support cost
20% of salary
Pay not spent (a real saving)
£20,769
Delivery impact over the period
£41,538
Internal hiring effort
£2,400
Net cost of the delay
£23,169
Recruitment support at those assumptions
£15,000
Delay costs more than the support by
£8,169

Which of your numbers scale with the delay

Two of them, and they pull in opposite directions. Delivery impact grows with every week the role is open, and so does the pay you are not spending — one adds to the cost, the other subtracts from it. Everything else in the model is a one-off: internal hiring effort is hours × hourly cost, and any project-delay figure you enter is a single amount. Neither grows as the vacancy runs on, so both become a smaller share of the total the longer it lasts.

What actually drives the time-dependent cost is therefore the NET of the two that do scale — your monthly delivery impact converted to a weekly figure, minus the weekly run rate of the role. That difference is what each extra week adds:

net cost per week = (monthly impact ÷ 4.33) − weekly run rate

If that is positive, waiting costs you money and the cost compounds week by week. If it is negative — the role's pay is worth more than the work it is not doing — waiting genuinely saves money, and the model will say so rather than manufacturing a reason to hire. Which single input matters most depends entirely on which side of that subtraction is larger for your role, so there is no general answer and this page does not offer one. If you have no defensible figure for delivery impact, leave it at zero and read the pay saving on its own.

Reading the 30, 60 and 90-day rows

Those rows are not a forecast of how long the hire will take. They answer a narrower question: at the assumptions you just entered, what does each further month of the role being empty add or save? The rate behind them is the same subtraction as above, expressed per day — monthly impact ÷ 30.42, minus the daily run rate — so a role whose absence costs little produces a negative figure, and a role holding up delivery produces a steep one.

Use them as an affordability test rather than a prediction. If another 90 days is comfortably affordable, the case for paying for help is weak whatever the headline says. If it is not, the comparison has already answered the question.

When recruitment costs less than waiting

Only when both halves hold: the support costs less than the net delay it removes, AND it genuinely shortens that delay. A fee that buys a faster process on a role nobody is waiting for is a cost with no return, and the arithmetic above will say so — that is the point of showing the pay saving separately rather than folding it into a single frightening headline.

See how the search services work →