Agency, Freelancer or In-House? How to Decide Who Builds Your Software

Before we start: we are an agency, so read this knowing that. We have tried to write the version we would want to read if we were deciding, which means saying plainly where the other two options are better — and they often are.

If you need to hire web developers for a project, there are three ways to do it. Each is right for a different situation, and the most expensive mistakes come from picking the wrong one rather than from picking a bad supplier.

The honest summary

Since the answer is usually clear from a few facts, here it is up front.

• One defined project, no ongoing need? An agency or a freelancer. Which depends on size.
• Small, contained piece of work? A freelancer, almost always.
• Software that is core to how the business makes money, changing constantly? In-house, eventually.
• Not sure what you need built? Whoever will scope it properly before quoting. That is the whole test.

The rest of this explains why, and what each option actually costs — including the parts that do not appear on an invoice.

Hiring a freelancer

One person, contracted for a piece of work or for a number of hours.

When it is the right answer

For a contained, well-specified piece of work, a good freelancer is the best value available. There is no agency overhead, you deal directly with the person doing the work, and the whole arrangement can start next week.

It is also right when you know exactly what you need. A freelancer given a clear specification will usually deliver it more cheaply than anybody else.

What it actually costs

The rate is the smallest part. The real costs are these:

You are the project manager. Somebody has to decide what happens next, check the work, and notice when something has gone wrong. With a freelancer that is you, and it is real time — often several hours a week that nobody accounted for.

One person, one skill set. Most freelancers are strong at either front-end or back-end, design or development. A project needing several will need several freelancers, and joining their work together becomes your problem.

No cover. If they are ill, on holiday, or take a better-paying project, your work stops. That is not a criticism of freelancers; it is arithmetic. One person cannot be two.

Continuity risk. The most common expensive story we see is a system built by a freelancer who is no longer contactable, with no documentation, that nobody else can safely change.

How to do it well

Specify tightly, in writing. Ask for documentation as a deliverable rather than assuming it. And make sure the code sits in a repository you own from day one rather than in one belonging to them.

Hiring an agency

A company, with several people, contracted for a project.

When it is the right answer

When the project needs more than one skill set, when you do not want to project-manage it, and when you want somebody accountable for the outcome rather than for their own hours.

It is also right when the requirements are not fully clear. Scoping is a skill, and a decent agency does it before quoting — which is worth more than it looks, because a project scoped properly is a project that ends when it said it would.

What it actually costs

You pay for the overhead, and it is not imaginary. Agencies carry people between projects, and that cost is in the rate. Whether it is worth it depends on whether you use what it buys — the cover, the range of skills, the person whose job is making sure it happens.

You may not get the person you met. This is the standard complaint about larger agencies, and it is fair. The people in the pitch are often not the people who build it. **Ask directly who will do the work**, and be suspicious of a vague answer.

Less flexibility mid-project. A fixed scope is what makes a fixed price possible. If you want to change direction halfway through, that is a change request — which is honest, but it is slower than telling one freelancer to do something different.

How to do it well

Ask who is actually building it. Ask what happens if the estimate is wrong — whose problem is it. And ask what you own at the end: the code, the accounts, the hosting, the documentation. **If any of those answers is unclear, that is your answer about the agency.**

Hiring in-house

Employing a developer, or several.

When it is the right answer

When software is how the business works rather than something the business has. If your product is the system, and it changes weekly, and the knowledge of how it works is a competitive asset — that belongs inside the company.

The other case is volume. Past a certain amount of continuous development, employing is cheaper than contracting. Below it, it is considerably more expensive.

What it actually costs

Far more than the salary. Add recruitment, equipment, tooling and licences, statutory costs, and the management time to keep somebody productive and interested.

The bench problem. An employed developer is paid whether or not there is a full week of work. That is fine at steady volume and expensive in the gaps.

Recruitment risk, and it is the big one. If you are not technical, you cannot reliably assess a developer’s competence at interview. Hiring the wrong one is a costly mistake that takes months to become visible — and the code they leave behind can outlast them by years.

One person is not a team. A single in-house developer has no one to review their work, no cover, and no one to disagree with them. That works until it does not.

How to do it well

Have somebody technical involved in hiring, even on contract for a day. Start with a contract-to-permanent arrangement if you can. And be honest about whether there is genuinely a full-time job there, or whether you have a series of projects that will look like one for six months and then stop.

The hybrid nobody mentions

The arrangement that works most often for a growing business is not one of the three.

Build the first version with an agency or a freelancer. Employ somebody to run it once it exists and matters.

This works because the two jobs are different. Building something from nothing needs a range of skills for a fixed period. Running and improving it needs one person who knows it well, continuously. Trying to hire for the first job usually means hiring the wrong person for the second.

It also removes the worst version of the recruitment risk. By the time you employ somebody, you have a working system, documentation, and enough understanding to judge whether a candidate can handle it.

The question that decides it

If you take one thing from this: the delivery model matters less than whether whoever you choose will scope the work properly before quoting.

Almost every failed software project we have seen — ours and other people’s — failed for the same reason. Nobody established what was actually being built before the money started being spent. The specification was three bullet points, everybody assumed they were agreed, and the disagreement surfaced in month two.

That failure is available at every price point and from all three models. A freelancer who starts coding on Monday, an agency that quotes off a phone call, an employee told to “sort out the website” — same outcome.

So the question to ask, of whoever you are considering, is: what will you do before you give me a price?

A good answer describes work. Mapping the process, documenting the requirements, checking what the existing systems can do, writing down what is included and what is not.

A bad answer is a number, immediately. Fast quotes feel efficient and they are the single most reliable predictor of a project that overruns — because the number was a guess, and guesses get corrected later at your expense.

Where to start

Write down what you need built, in terms of what people will be able to do with it. Then take that to two or three of the options above and compare how they respond to it — not just what they charge.

The one that asks the most questions before quoting is usually the one to pick, regardless of which of the three models it belongs to.

If you want to see how we would approach it, our web development and custom web application development services both start with scoping before any price is agreed. And if what you need turns out to be smaller than a project — two systems talking to each other, or one process automated — we will tell you that instead, because a small piece of work delivered well is worth more to both of us than a large one nobody needed.