Hire a developer or use a studio: the sum nobody does

The question comes up every time, and it is a fair one: why pay a supplier when you could hire somebody?

The sum people do instinctively is simple. An experienced developer costs so much a month. A studio charges so much a day. Multiply, compare, and hiring wins comfortably.

That sum is not wrong. It is incomplete, and what it leaves out is often worth more than what it counts.

What the sum leaves out

The wait before you have anybody. Between the decision and the first day, allow three to six months for a senior profile — writing the role, sourcing, interviews, notice periods. Meanwhile the process you wanted to support keeps running on a spreadsheet.

The wait before they are productive. A good developer is not useful on day one. They are useful once they understand your business: your rules, your edge cases, what happens at month end. In a dense domain — grocery retail, logistics, anything regulated — allow several months more.

The full cost. Gross salary is not the cost. Add employer contributions, paid leave, health cover, equipment, licences, training, and a share of management time — because a lone developer in a company that has no others needs somebody to arbitrate.

Key-person risk. This is the most expensive line, and it appears in no budget. One person writes the code, knows the architecture, and knows why each decision was taken. The day they leave — and one day they will — all of that knowledge leaves with them. You are not hiring a replacement: you are starting again.

The troughs. A software project does not have a constant workload. Design and launch demand a lot; maintenance demands far less. An employee costs the same in both phases.

The real sum

It is not a salary against a day rate. It is two complete scenarios over three years.

On the hiring side: the cost of recruiting, the full cost of the post over three years, the months of non-production at the start, and a non-zero probability of having to do it all again once.

On the studio side: the cost of the project, plus annual maintenance — which is a fraction of the initial build.

That sum does not always produce the same winner. Which is precisely why it is worth doing instead of deciding on reflex.

When hiring is the right call

This needs saying plainly, because it is true more often than a supplier likes to admit.

When you already have a technical team. One more developer in a team that exists is immediately supported, reviewed and integrated. The key-person risk disappears. This is by far the most favourable case.

When the software is your product. If what you build is what you sell, it has to be yours in capability as much as in ownership. An in-house team is the only durable answer.

When the workload really is continuous. A roadmap full for two years is not an engagement, it is a job.

When a studio is

When the need has edges. Getting a process out of a spreadsheet, connecting two systems, building an operational tool: these are projects with a beginning and an end, followed by light maintenance.

When you have no technical team. Hiring an isolated developer into a company that has none creates a point of fragility, not a capability.

When time matters. Six months of hiring plus six months of getting up to speed, or a first version in a few weeks: these are not the same project.

When you want to know before committing. This is our argument, and hiring has no equivalent to it: you will only know whether the software suits you by watching it run. So we start with a small scope and a working prototype. If it does not suit you, it is not invoiced. A bad hire, by contrast, is paid for in full.

The question that settles it

One question, and it is simple.

Does this software need to change every month for the next five years?

If yes, you need a team, and bringing it in-house always turns out to be the right answer.

If no — if what you need is for a critical process to stop running on files, and then to be maintained properly — then you do not have a hiring problem. You have a project.