Most comparisons of hiring a developer against engaging an agency put a salary next to a day rate and stop there. That comparison is close to meaningless, because it leaves out everything the salary line does not capture: the months before the hire is productive, the recruitment fee, the employer’s National Insurance and pension contributions, holiday and sickness cover, and the management attention a permanent engineer needs and a supplier does not.
We sell agency work, so read what follows with that in mind. We have also tried to be specific about the situations where hiring in-house is the better decision, because those situations exist and pretending otherwise wastes everybody’s time.
What is actually in the cost of a permanent hire
Take whatever salary you are budgeting and add these, none of which appear on the payslip.
- Employer costs. Employer’s National Insurance, the pension contribution, and the apprenticeship levy if your payroll is large enough. This is a meaningful uplift on the headline salary before anyone has written a line of code.
- Recruitment. An agency fee is typically a percentage of first-year salary. If you recruit directly you pay in job advert spend and in the time your existing team spends screening and interviewing, which is engineering time not spent building.
- Time to hire. From opening a role to a start date, with a notice period, is commonly a matter of months. That is months in which the problem you are hiring to solve continues unsolved.
- Time to productive. A good senior engineer joining an existing codebase is contributing usefully within weeks and fully effective some months in. A junior takes considerably longer, and consumes a senior’s time while doing so.
- Non-working days. Statutory holiday, bank holidays, sickness, training. A permanent engineer is paid for roughly 260 weekdays and works appreciably fewer.
- Management. One-to-ones, reviews, career conversations, objective setting. Real work, and it comes out of somebody’s week.
- Tooling and overhead. Laptop, licences, cloud accounts, desk if you have offices, HR and payroll administration.
- Attrition risk. The one that hurts most. If your engineer leaves after eighteen months you repeat the recruitment cost and the ramp-up, and if they were your only engineer you also lose the only copy of how the system works.
The single-engineer version of this is the worst position of all, and it is remarkably common in companies of twenty to a hundred people. One developer means no code review, no second opinion on architecture, no cover for holiday, and a bus factor of one. The cost of that arrangement does not show up until the day it fails.
Contractors
A contractor is the fastest route to capacity. Days rather than months to start, no recruitment fee, no notice period, and you pay only for days worked. For a defined piece of work with a clear specification and a competent person already in-house to direct it, this is frequently the most efficient option available.
The costs that do not appear on the day rate are these. IR35 status has to be assessed properly, and getting it wrong creates a tax liability that lands on the client, not the contractor. There is no cover: a contractor’s holiday is your gap. There is no bench, so if the work turns out to need a skill they do not have, you find another contractor. And a contractor working alone produces the same bus-factor-of-one problem as a lone employee, with a shorter engagement and often less incentive to document.
The other genuine risk is direction. Contractors are usually paid for time, not outcomes. If nobody internally is competent to review the work and say “that is not the right approach”, you can spend a great deal of money on code that functions and is nonetheless wrong.
Agencies
An agency day rate is higher than a contractor’s and much higher than the implied daily cost of a salary. What that premium buys, when the agency is any good, is a set of things that are individually expensive to build yourself.
- No recruitment lead time or fee, and no cost if it does not work out beyond the notice in the contract.
- A mix of skills without a mix of hires. Most builds need a bit of infrastructure work, a bit of design, a bit of data engineering and a lot of application development. Hiring one person to cover that produces a generalist with gaps; hiring four is not affordable at this scale.
- Continuity through absence. Holiday and illness are the supplier’s problem to solve.
- Existing practice. Deployment pipelines, code review, monitoring, backup and restore procedures. A new in-house team builds all of that from nothing, and it takes months that nobody budgets for.
- Contractual accountability. You can hold a company to a scope and a warranty in a way you cannot hold an employee.
The costs the day rate hides: your own time managing the relationship, which is real even with a good supplier; the risk of knowledge accumulating outside your company; and the switching cost if the relationship ends badly. Those last two are manageable, but only if you insist on them being managed. Owning the repositories and the cloud accounts, requiring documentation as a deliverable rather than a favour, and having your own people in code reviews are the mechanisms. A supplier who resists them is building dependency deliberately.
When you should hire in-house instead of calling us
Hire permanently when the work is continuous and open-ended. If software is how your company makes money, and there will still be a full queue of work in three years, the economics eventually favour employment, and the strategic argument favours it well before the economics do. Capability you rent is capability you can lose.
Hire permanently when the work requires deep, slowly-acquired knowledge of your domain — pricing rules, clinical pathways, regulatory detail that took your business a decade to learn. An external team can learn a domain, but the payback period on that learning only makes sense across a long engagement.
Hire permanently when responsiveness matters more than throughput. Someone who can be interrupted, who sits in the operations meeting and hears the problem being described, will catch things no scheduled sprint review surfaces.
And hire permanently if you already have a functioning engineering team with capacity. Adding an agency alongside an in-house team that could do the work creates coordination overhead and, usually, resentment.
When an agency is the right answer
When the work has an end. A build, a migration, an integration, a platform to get to launch. Employing someone permanently for a nine-month project means either a redundancy or a made-up job at the end of it.
When you do not yet know if the thing is worth doing. Committing to a permanent hire before you know whether the product has a market is an expensive way to find out.
When you cannot credibly recruit for the role. If nobody in your company can assess a senior engineer’s technical judgement, you cannot reliably hire one, and you will find out slowly and expensively.
When the work needs a spread of specialisms for a short period — an IoT deployment needing firmware, connectivity and a cloud back end, or a data platform needing pipelines, modelling and a front end. That is several people’s expertise for a few months each.
The hybrid most companies end up with
The arrangement that works best in practice is a supplier building the initial system alongside one strong internal hire whose explicit job is to absorb it. The company gets speed and breadth at the start, and ends up owning the capability. It costs more in the first year than either option alone and much less over three, and it removes the dependency problem by design.
If you want a single question to decide with, it is this one: will there still be a queue of software work for this person in two years’ time? If yes, start hiring now and use a supplier to cover the gap. If no, do not create a job you will have to end.