One-person studio or agency: which should you hire?

An agency has quoted, a one-person studio has quoted, and the gap between the two numbers is wide enough that it has to mean something. It does mean something, though not always what the cheaper quote suggests.

I run a one-person studio, so bear that in mind as you read the rest. This is the argument I'd make to a friend, including the parts that send you elsewhere.

When an agency is the right call

Several workstreams at once. If a designer, a back-end developer and someone writing the copy all need to be working in the same fortnight, one person does those in sequence, and sequence is slower. Where the date's fixed and the scope is wide, an agency can put several people on it at once.

Guaranteed cover. More than one person can pick the work up, so holiday, illness or somebody leaving slows the work down without stopping it. If a lost month would hurt the business, that guarantee is worth paying for.

Procurement. Plenty of organisations can't contract with a sole trader or a small company at all, because of a minimum turnover, a headcount floor or a level of professional indemnity cover. Arguing with a policy somebody else wrote wastes everyone's time, so find out early, before anyone writes a proposal.

Design, brand and copy. If you want those alongside the build, they're separate disciplines. A developer who also designs isn't a design team, and if you treat one like a design team, you'll probably get a system that works fine and looks plain.

A project manager. Past a certain size, coordination is a job in itself. There are people to keep in the loop, a schedule across teams, and approvals on your side, and if a project manager isn't doing it, you are.

Someone still there in five years. If the system will be load-bearing for a decade and you want a contractual answer to who maintains it, a company with a support desk is a different kind of offer.

When one person is the right call

You brief the person who codes. Nothing gets lost being passed along. Most of what matters in a business system never reaches the specification anyway. It's in the passing sentence about the one client who gets handled differently.

No account manager. That role is needed at a certain size, and the good ones earn their keep. It still means a question about one field has to travel through somebody to reach the person who knows.

Decisions in a conversation. There's no change-request process. If something looks wrong in week three, you say so and it changes that afternoon.

Less overhead in the price. That's not waste. An agency just has costs a one-person studio doesn't.

All the context in one head. I think this matters most where the hard part is understanding the business more than writing the code. On the lead data platform, the engineering wasn't the difficult bit. Working out that validation sat at the wrong point in the process was, and that came out of a conversation. It wasn't in any brief.

The risks of hiring one person

These are real, and none of them are solved.

Bus factor. If something happens to me, your project stops. Documentation and code that transfers to you mean someone else can carry it on, so losing me hurts less, but the work still stops for a while.

Capacity. I take a small number of projects at a time, which is how I protect my attention, and it also means I sometimes can't start when you want me to. There's no bench.

Holidays and illness. A fortnight off is a fortnight where nothing moves. All I can do is tell you early.

Nobody to escalate to. If you're unhappy, you raise it with the person who did the work, because there's no account director above me. A written scope and a fixed price mean fewer disputes to have, but they don't put a second party in the room.

No internal challenge. Nobody reviews how I've designed the system before you see it, whereas in an agency someone senior might push back on a design before it reaches you. Here the checks are your own scrutiny, the reasoning being written down, and a second opinion bought elsewhere when a decision warrants it.

Parallel work. Things happen one after another, so if four things must happen in the same three weeks, they won't.

What to ask either one before you sign

Ask both of them all five. I think the answers tell you more than a portfolio does.

1. Who actually writes the code? Is the person in the pitch the one building it, and is any of it subcontracted? Subcontracting is fine. Not being told about it isn't.
2. What happens if you're unavailable? Press past "we have a team" to who specifically, and what the handover between them looks like.
3. What do I get at handover? Running software, the repository, accounts in your own name, and documentation somebody else can work from. Ask what documentation means in practice, because it can mean very different things.
4. Can I take this to someone else? Who owns the code, and from when. Whether it's an ordinary stack another developer can pick up, or a proprietary platform only they maintain.
5. What happens if we disagree about scope? Whether it's written down, whether revision rounds are defined, and how a change gets priced.

My own answers to those

I work to a fixed price against a written scope, agreed before any code. It's paid in stages against what's been delivered, not against dates. You decide what it needs to do, and I decide how it's built.

Code and assets I create stay mine until final payment and full handover, and at that point they transfer to you. Where a licence is under discussion, usually for something you intend to sell, ownership stays with me and you licence it, which lowers what you pay up front. Whichever applies is written into the proposal.

Handover means everything running, handed over and written down, including the accounts, the documentation and how to keep it going. So what covers you is a proper handover, not more people, and that's a different promise from the one an agency makes.