Alternatives to hiring a full-time developer

At some point most growing businesses have the same conversation. The software matters now. Things keep needing changing. Should we hire somebody?

It is the obvious next step, and for some businesses it is the right one. But it is worth doing the arithmetic properly before committing, because the true cost of a developer is considerably higher than the salary, and the amount of work most small businesses actually have is considerably lower than a full-time role.

What hiring really costs#

The salary is the part everybody knows. It is not the number to plan with.

A developer in the UK outside London is typically somewhere between £35,000 and £60,000 depending on experience, and more for senior people or in-demand specialisms. On top of that a full-time employee brings employer national insurance, a pension contribution, holiday and sick cover, equipment, software licences, and recruitment fees if you use an agency, which commonly run at fifteen to twenty percent of the first year's salary.

As a rule of thumb, the all-in cost of an employee is meaningfully above their salary once all of that is counted. Whatever figure you had in mind, the real one is higher.

Then there are the costs that do not appear on a spreadsheet at all.

Somebody has to manage them. Deciding what they work on, reviewing whether it was done well, and handling it when it was not. If nobody in the business can judge the quality of the work, that is a real exposure rather than a minor gap.

One developer is a single point of failure. They go on holiday. They get ill. Eventually they leave, and when they do, everything they knew and never wrote down leaves with them. We are called in after that happens more often than after any other single event.

A developer alone has nobody to learn from. Good engineers get better by working with other engineers. A solo developer in a non-technical business gets more isolated rather than more capable, which is also why they tend not to stay.

The question that decides it#

Here is the one that settles it for most people, and it is uncomfortable to answer honestly.

How many days of development work do you actually have in a year?

Not "how much would we like to change eventually". How much real, defined work exists. Write the list. Most small businesses, doing this properly, find somewhere between fifteen and sixty days of work a year.

A full-time developer gives you around two hundred and twenty working days. If your list is forty days long, you are paying for a hundred and eighty days of something else, and what typically fills them is not nothing. It is a developer finding work to do, which is how businesses acquire systems they did not need and now have to maintain.

The options, honestly#

Hire someone full-time. Right when software is central to what you sell, when there is more than a year of continuous work visible, and when somebody in the business can judge technical quality. It buys availability and deep familiarity with your systems, which are real advantages.

A part-time or fractional developer. Fits some businesses well, though be careful about what happens when you need them and they are with another client. Ask about the notice they need and what their other commitments look like.

A freelancer per project. Flexible, often good value, and the variable is the individual rather than the model. The usual risk is continuity: the person who built it may not be available in two years, and freelancers are the most likely of all these options to move on.

An agency retainer. Buys a monthly allocation of time. It suits businesses with steady, predictable demand. It suits businesses with lumpy demand badly, because unused hours generally do not roll over for ever and you pay in the quiet months.

Per job, with a fixed price. You pay for the work you have, when you have it. There is no standing cost between jobs. The trade-off is that you are one of several clients rather than the only one, so availability is not instant, and it works less well if you need somebody available at short notice every week.

Off-the-shelf software. The option people skip when they are already in the mindset of building something. Frequently the correct answer, and a supplier who never mentions it is telling you something about themselves.

Working out which one you are#

Three questions, and they are about your business rather than about software.

Is software what you sell, or what you use? If customers pay for the software itself, hiring becomes much more defensible, because the capability is the product. If software runs the business but is not the business, buying it by the job usually wins.

Is the work continuous or occasional? Continuous means a stream of work that does not stop. Occasional means bursts with quiet periods. Continuous favours employment, occasional favours per-job.

Could anyone here tell good work from bad? If not, employing somebody puts you in a position where you cannot evaluate your most important supplier, and they happen to be on your payroll. That is worse than the same problem with an external supplier, because it is harder to end.

The middle path most people miss#

It does not have to be one or the other, and the combination that works well for a lot of small businesses is this: buy the occasional work by the job, and spend the money you saved on knowing what you have.

Which means a written description of your systems, access to every account in your own name, a backup you have tested yourself, and a supplier who could be replaced without the business stopping. That costs a fraction of a salary and it removes the actual risk, which was never "we do not have a developer". It was "we could not cope if our developer went away".

When we say hire somebody#

We are not a neutral party here, so it is worth saying where we would tell you to go elsewhere.

If you have more than a year of continuous work in front of you, and software is central to what you sell, and somebody in your business can judge the work, hire. You will get better value from an employee than from us, and we would rather say that than sell you something that does not fit.

What we do#

We work job by job. You describe what you need, it gets graded by size, and you get a price in writing before anything starts. Nothing begins until you approve it, and there is nothing to pay between jobs.

No retainer, no minimum, and no contract committing you to a volume of work you may not have. A business with ten days of work a year is a perfectly good client, and so is one with a hundred.

Every account is in your name from the first day: the repository, the hosting, the domain, everything the system runs on. On the code we keep the copyright, and you hold a perpetual licence to use it for your project, change it, and have anybody at all change it. It does not lapse when we stop working together. What you cannot do is sell that code on, or use it as the basis of a different product, without our agreement. That is the part that matters for this decision, because it means choosing us is not a lock-in. If you later hire somebody, they pick it up and carry on.

That last point is the honest version of the pitch. The best outcome for some of our clients is that they outgrow buying work by the job, and the systems should be built so that when that day comes, nothing has to be unpicked first.