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 work, and the ones that do usually know it already.
Every studio we work with has had this conversation, usually more than once. Web projects keep arriving, sub-contracting feels like giving margin away, and hiring starts to look like what a proper agency would do.
Sometimes it is. More often it isn't, and the reasons are duller and more arithmetical than the conversation usually allows. We'd obviously prefer you didn't hire, so read the following with that in mind, but the numbers are checkable and the failure modes are ones we've watched happen.
It's a fixed cost sitting against variable work
Public salary data puts a senior UK web developer somewhere between £35,000 and £55,000 a year. That's the headline. Add employer's National Insurance, pension, equipment, software licences, holiday cover, and the recruitment fee to find them in the first place, and the annual cost is well above 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.
Whether you can afford a developer is the easy question. The harder one is whether you have enough continuous build work to keep one busy, and whether you'd rather carry that risk yourself than pay per project.
The utilisation problem nobody plans for
A developer with no build to work on doesn't sit idle, because that would be visible. They find work: they rebuild the studio's own website, start a tooling project, take on small internal jobs that are useful and bring in no revenue.
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 spreadsheet doesn't record the cost of the quiet quarter. The studio website that's been redesigned three times does.
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 out of proportion.
They take a fortnight's holiday and launches move around it. They're ill during launch week and you're phoning freelancers who have never seen the codebase. Then 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, ends up with private conventions. Not bad ones necessarily, just theirs: undocumented, obvious to them and opaque to everyone else. It 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, usually a founder, and it comes out of the hours they were meant to spend selling. It's rarely costed, because it looks like management rather than a cost.
The salary never surprises anyone. The two days a month a founder spends line-managing a discipline they don't practise does.
And you'll need to keep them
A good developer at a design studio is often 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 work notice this in about eighteen months. Retention becomes a cost, whether 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 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 rather than lumpy build work; when you can hire at least two people so nobody is working alone; and when you have somebody senior who can review the work properly and make architectural calls.
At that point an in-house team beats any partner, us included. They 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 much tighter. We can't match that.
The mistake is hiring the first person on the way to that state and expecting the benefits of the finished one.
The middle option, where most studios 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 and no archaeology when somebody leaves. The margin is yours to set. UK studios commonly report somewhere between 40 and 60% gross margin on white-labelled build work, which is what makes the arrangement viable rather than just convenient.
The trade is that you're managing a relationship rather than a person, and the quality of that relationship matters a great deal. 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 decide
Take the last two years. Count the months in which you had a web build in progress. If it's most of them, and the trend is upward, hire, and hire two people rather than one.
If it's fewer than half, you're thinking about 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.