We get asked this by businesses about to hire their first developer, and we have an obvious interest in the answer. So let me be clear about where that interest sits: if you have enough ongoing work to keep a developer busy, hire one. We will say that on a call and we have said it to people who arrived ready to sign.
What follows is how to tell which situation you are in.
What a developer actually costs
Take the salary and add roughly 30%. Employer's National Insurance, pension, equipment, software licences, a desk if you have desks. A £55,000 developer is about £72,000 a year before anyone has written a line.
Then add the part nobody budgets. Recruitment is either 15 to 20% of salary through an agency or a large amount of your own time. The first three months are ramp up: they are learning your business, your systems and your customers, and they are not yet producing at full speed. And if you have nobody technical already, you are hiring someone you cannot assess, managing someone whose work you cannot review, and hoping.
None of that makes hiring wrong. It makes hiring an investment with a payback period, which is a different question from a monthly cost.
The test
The honest one is this: do you have twelve months of work you can describe today?
Not twelve months of ideas. Twelve months of things you know you need, in enough detail that you could explain them to someone on their first day. If you can, hire. A permanent developer who understands your business gets more valuable every year in a way an outside studio never quite does. You should want that.
If you cannot, you are looking at a series of projects with gaps between them. A permanent hire spends those gaps doing something other than what you hired them for.
When outsourcing is the better answer
The work is a project, not a stream. An integration, a portal, an internal tool. It has a beginning and an end, and when it ends there is not obviously another one behind it.
You need it faster than you can hire. Recruitment plus notice plus ramp up is realistically five to six months before someone is properly productive. A studio starts in two to four weeks.
You cannot assess the hire. This is the one people underestimate. If nobody in the business can read code, your interview is a conversation about confidence, and you will find out in month four whether you got it right. Outsourcing at least gives you a fixed price and something delivered.
You need a range of skills briefly. A build often wants design, front end, back end and infrastructure. That is four skill sets and you were going to hire one person, who will be strong at one of them.
The work is genuinely one off. Migrations, rebuilds, rescues. Hiring permanently for a job that finishes leaves you with a decision you will not enjoy making.
When hiring wins, plainly
The software is the business. If your product is software, the people who build it should be yours. Do not outsource your core.
It changes constantly. Some systems need daily judgement calls about the business. That is a person in the room, not a scoped project.
You already have a technical lead. Someone who can interview well, review work and bring a junior on. That changes the risk profile completely, and it is usually the point at which businesses stop needing us for capacity.
It is genuinely full time, indefinitely. At that point outsourcing is more expensive and you are renting something you should own.
The arithmetic, roughly
A permanent developer is about £72,000 all in, so about £6,000 a month, working at full effectiveness from month four.
Outsourced, the same money buys perhaps eight to ten days a month of senior time from a team. Fewer hours, more skills, no ramp up, no recruitment, and it stops when the work does.
Below about six months of work, outsourcing usually wins. Above about eighteen months of continuous work, hiring usually wins. Between the two it depends on how well you can describe what you need and whether you can judge who you are hiring.
The option people forget
You do not have to choose immediately.
A common route, and often the right one: outsource the first project, keep the code and the documentation, and use it to work out how much ongoing work there actually is. Twelve months later you know whether the stream is real, and you are hiring against a system that exists rather than a plan that might.
We have handed several clients to their first permanent developer that way. It ends the arrangement, which is fine. It was the right advice, and the ones who did it tend to come back for the next thing.
