Why you probably shouldn't hire an in-house developer
A developer is a fixed cost against variable work. Most studios don't have the pipeline to make that maths land, and the ones that do usually know it already.
Every studio we work with has had the conversation, usually more than once. Web projects keep arriving. Sub-contracting feels like leaking margin to somebody else. Hiring starts to look like the grown-up answer, the thing a proper agency would do.
Sometimes it is. More often it isn't, and the reasons are duller and more arithmetic than the conversation usually allows for. Since we'd obviously prefer you didn't hire, treat the following with appropriate suspicion — but the numbers are checkable and the failure modes are real.
It's a fixed cost sitting against variable work
Public salary data puts a senior UK web developer somewhere in the region of £35,000 to £55,000 a year. That's the headline. Add employer's National Insurance, pension contributions, equipment, software licences, holiday cover, and the recruitment fee to find them in the first place, and the real annual cost is meaningfully north of the number you'd advertise.
That cost arrives every month, whether or not there's a build in the studio. And web work, for a design-led studio, almost never arrives every month. It arrives in a lump after a brand project completes, then nothing for a quarter, then two at once because both clients approved in the same fortnight.
So the real question isn't whether you can afford a developer. It's whether you have enough continuous build work to keep one usefully busy, and whether you'd rather carry that risk yourself than pay per project.
The utilisation problem nobody plans for
Here's the version that catches studios out. A developer with no build to work on doesn't sit idle — that would be visible. They find work. They rebuild the studio's own website. They start a tooling project. They take on small internal jobs that are genuinely useful and generate no revenue at all.
By the time the next real build arrives, they're mid-way through something they care about, and there's a conversation about priorities that nobody enjoys. The cost of the quiet quarter doesn't show up as an obvious gap in a spreadsheet. It shows up as a studio website that's been redesigned three times.
One developer is a single point of failure
A studio with one developer has a bus factor of one, and every consequence of that is disproportionate.
They take a fortnight's holiday and launches move around it. They're ill during launch week and you're phoning freelancers who have no context on a codebase they've never seen. They hand in their notice and every site they built becomes an archaeology project.
That last one is the expensive one and it isn't a criticism of the person. A developer working alone, with nobody reviewing their work, inevitably develops private conventions. Not bad ones necessarily — just theirs, undocumented, obvious to them and opaque to everyone else. It's what happens to anyone working without a second opinion, in any discipline.
When they leave, you own several sites that only made sense to somebody who no longer works there, and the next developer's first estimate will reflect that.
You'll spend management time you didn't budget for
Design directors are good at directing design. Technical management is a different job: code review, technical estimating, architecture decisions, keeping somebody current in a field that moves, and knowing whether "that'll take three weeks" is true.
That job lands on whoever in the studio is least bad at it, which is usually a founder, and it usually comes out of the hours they were meant to spend selling. It's rarely costed, because it doesn't look like a cost. It looks like management.
The cost that surprises studios isn't the salary. It's the two days a month a founder spends line-managing a discipline they don't practise.
And you'll need to keep them
A good developer at a design studio is frequently the only developer at a design studio. There's nobody to learn from, no code review, no technical progression, and the interesting architectural problems are rare because the work is mostly marketing sites.
Developers who care about their craft tend to notice this in about eighteen months. Retention becomes a real cost — either in salary, in finding them side projects, or in replacing them every couple of years and paying the archaeology tax each time.
When hiring is genuinely the right answer
We'd rather say this plainly than pretend the case doesn't exist, because it does and we've watched studios get it right.
Hire when web is a standing part of what you sell rather than an occasional add-on. Specifically: when you have continuous build work rather than lumpy work; when you can hire at least two people so nobody is working alone; and when you have somebody senior who can genuinely review the work and make architectural calls.
At that point an in-house team beats any partner, us included. They'll carry context we never will, they're in the room during the design conversation rather than receiving its output, and the feedback loop between design and build gets dramatically tighter. That's a real advantage and it's not one we can replicate.
The mistake is hiring the first person on the way to that state and expecting the benefits of the finished state.
The middle option, where most studios actually live
Most studios sit between those two states for years, and some sit there permanently and do very well. The model that works there is a partner engaged per project.
No fixed cost during a quiet quarter. No recruitment scramble when three land at once. No management overhead, no retention problem, no archaeology when somebody leaves. And margin that's yours to set: UK studios commonly report somewhere in the region of 40–60% gross margin on white-labelled build work, which is the number that makes the whole arrangement viable rather than merely convenient.
The trade is that you're managing a relationship rather than a person, and the quality of that relationship matters enormously. A partner who needs thirty questions answered across three weeks will make you wish you'd hired. One who asks six at the start and then goes quiet won't.
How to actually decide
Take the last two years. Count the months in which you had a web build genuinely in progress. If it's most of them, and the trend is upward, hire — and hire two people, not one.
If it's fewer than half, you're considering converting a variable cost into a fixed one because the fixed one feels more like a real business. It's an understandable instinct and an expensive one.