The question usually arrives as a straight choice: do you hire a freelancer or an agency, with "a firm" floating somewhere in the background as a vaguer, more expensive third option. The labels feel like they capture the decision, and they sort the options by the wrong thing, which is roughly how big the team is. The straight version is this: a freelancer, an agency, and a firm are priced and structured for genuinely different jobs, and the variable that actually predicts whether you end up with working software is none of those labels. It is who owns the outcome once the thing is built and has to keep running.
We have taken apart the related fractional CTO versus agency choice, which is about direction against delivery. This piece is about the building itself. When the job in front of you is to get software made, who should make it, and what does each option leave you holding a year later.
What is a freelancer priced for?
A freelancer is one skilled pair of hands, bought for bounded, well-specified work. Hand a good independent developer a clear scope, a defined feature, a fix, a small build, and you get the cheapest correct answer there is, with no overhead and a direct line to the person doing the work. For a discrete job with clean edges, that is exactly right, and anyone who tells you to buy more is selling.
The model breaks on three things, and all of them show up over time rather than at the start. Coverage: when your one person is on a plane, unwell, or busy with another client, the work simply waits. Range: one developer is deep in some things and shallow in others, and a real system spans more than any single person's depth. Continuity: the context lives in one head, so if that person moves on, the reasoning behind every earlier choice can leave with them. For a one-time job none of that matters. For something the business will depend on and keep changing, all three do.
What is an agency priced for?
An agency is a team bought for a scoped project with an end date. The deliverable is the artefact itself, the site, the application, the integration, made by several people who each bring a craft, and what you are buying over a freelancer is capacity and range of hands. For a defined build that needs more than one skill set delivered on a schedule, that is precisely the right shape.
The limit is the other half of the same coin. An agency is structured around projects, not around owning a business's technology over the long run. It will build well what it is asked to build; whether the right thing was asked for is generally treated as your question, not theirs. And the relationship is built to end: when the project ships, the team rotates onto the next client, and the deep knowledge of how your system actually works goes with them unless something was put in place to keep it. You get the thing built. What you do not automatically get is anyone who stays accountable for how it performs after the invoice is paid.
What does a firm hold that the other two do not?
A firm, in the sense that matters here, is set up to decide, build, and keep running, with one party accountable for the result across all three. It carries the range of an agency and adds the two things an agency and a freelancer each lack: continuity held as a matter of structure rather than one person's memory, and ownership of the outcome rather than the deliverable. The advice comes with an engine room that can prove it; the build comes with someone who answers for it once it is live.
That is the real distinction, and it is not about headcount. A firm is the shape that can say, in writing, "this is ours to get right and keep right," and mean the running system, not the handover. When a recommendation needs proving, it can put real work behind it in days. When the thing breaks at an awkward hour, there is a single name attached to fixing it rather than a debate about whose phase the fault belongs to.
| Dimension | Freelancer | Agency | Firm |
|---|---|---|---|
| Priced for | Bounded, well-specified work | A scoped project with an end date | Deciding, building, and keeping it running |
| What you get | One skilled pair of hands | Capacity and a range of hands | Range, plus continuity and outcome ownership |
| Owns | Their slice | The build to spec | Whether the thing actually works |
| Continuity | Lives in one head, leaves if they do | Rotates onto the next client when the project ships | Held as a matter of structure |
| Characteristic failure | Single point of failure | The well-built wrong thing | Carries the cost of the people who stay accountable |
| Right when | The scope is clear and fits one person | You own the direction and need it built on a schedule | The outcome is ambiguous and must run for years |
A label tells you how big the team is. It does not tell you whose problem it is when the thing you paid for stops working.
The three ways this goes wrong
Each option has a characteristic failure, and recognising yours early is half the decision. The freelancer failure is the single point of failure: the build outgrows one person, or that person becomes unreachable, and the work stalls with nobody else holding the context. The agency failure is the well-built wrong thing: a team delivers exactly the spec it was handed, ships it, and moves on, and only later does it emerge that the spec was the problem and nobody owned that question.
The third failure is the one owners back into while trying to be clever: splitting direction and delivery across two parties so that neither owns the result. An advisor sets the direction, a separate team builds to it, the outcome underperforms, and each can point a true finger at the other. We have written about that split in detail; the short version is that dividing the work divides the blame, and the owner is left holding software that nobody will repair without a third invoice.
The real question: who owns the result
So the useful question is not which label to buy. It is this: when the software you paid for does not work, whose problem is it. Whose name is on the outcome rather than on the hours billed along the way. A freelancer owns their slice. An agency owns the build to spec. A firm, by design, owns whether the thing actually works and keeps working. A split owns nothing, which in practice is the same as no owner at all.
That single variable predicts the result more reliably than price, size, or pedigree. It is why two engagements at the same budget can end so differently: one had a clear owner of the outcome from the first call, and the other had capable people who each owned only a piece. Sort the options by where accountability lands, and the right choice usually becomes obvious.
How do you tell which one your project needs?
Three questions settle most of it. First, is the scope clear and bounded, the kind of job that has a clean definition of done. If yes, and it fits one person's range, a freelancer is the right and cheapest answer. Second, is this a defined project where you already own the direction, your own or a trusted advisor's, and you mainly need it built well on a schedule. If yes, an agency is right, and it will build it better than a half-resourced generalist could.
Third, is the outcome genuinely ambiguous, something that has to run for years, that spans more than one craft, and that you cannot personally own the direction of. If yes, what you need is a single party that decides, builds, and stays accountable, because dividing any of those will leave the result ownerless. The honest test underneath all three is whether the thing you are buying has a clear owner of done who is not you.
There is an earlier question worth asking before any of this, which is whether to build the software at all or buy something that already exists. When that one is live, the cleanest first move is an independent read from someone with no stake in the build, so the answer is not shaped by who would get the work. The engagement below is exactly that: a scoped advisory read, fixed in time and price, with a written recommendation an owner can take to a board and defend before a line of code is committed.
