Should you hire one senior developer or an agency?

Should you hire one developer or an agency?

Hire one senior developer when the project is a single coherent piece of work that one experienced person can hold in their head, and when you value a direct line to the builder over guaranteed capacity. Hire an agency when the work needs to happen in parallel, when continuity must survive one person being unavailable, or when your procurement process requires a vendor with a company structure behind it. Both are correct answers to different questions, and the failure mode is picking on price rather than on shape.

When is one senior developer the better choice?

The conditions where one person genuinely wins:

• The scope is one product or one substantial feature, not a programme of work.
• You can brief it yourself and want to talk to the person building it, without a translation layer.
• The problem is hard rather than large — the difficulty is in the thinking, not in the volume of screens.
• You have been burned by work being sold by one person and delivered by somebody more junior.
• You need someone to tell you when your plan is wrong, which is easier from a person with no sales target attached to the answer.

The common thread is that the cost of coordination exceeds the benefit of extra hands. Below a certain project size, adding people makes delivery slower, and a surprising number of projects are below it.

When is an agency genuinely the better choice?

Frequently, and anyone selling you one person who will not say so is not being straight with you. Choose an agency when:

• The work has to be done in parallel — iOS, Android, backend and design all moving at once against a fixed date.
• You need continuity guarantees: somebody else picks it up if the primary developer is ill, leaves or stops answering.
• You need 24/7 on-call, or a contractual response-time SLA.
• You need disciplines beyond engineering — product design, QA, security audit, accessibility review — and do not want to assemble that yourself.
• Your procurement or compliance process requires vendor insurance, supplier audits or a named account structure.
• The project is genuinely large. One person cannot build what ten people can, and the honest version of that sentence has no caveats.

What do you give up by going through an agency?

Three things, consistently. First, resolution: your intent reaches the code through an account manager, a project manager and possibly a specification document, and detail is lost at every step. Second, seniority — the person who sold the work is frequently not the person who does it, and the substitution is usually downward rather than upward. Third, margin, because an agency is carrying overhead you are funding whether or not it benefits your project.

None of that makes agencies bad. It makes them a trade: you are buying capacity and continuity with some directness and some money. If capacity and continuity are what the project needs, that is a good trade.

How do you tell a senior developer from a cheap one?

Rates tell you very little, and years of experience only slightly more. What separates them is visible in a first conversation if you ask for it:

1. Ask them to describe a project that went badly and what they would do differently. Someone with no such story is either inexperienced or not being candid.
2. Ask what work they turn down. A developer who claims to take on anything either has no judgement about fit or is about to learn your stack on your budget.
3. Watch whether they ask about failure cases, data and users, or only about features. Seniority shows up as curiosity about what happens when things go wrong.
4. Ask how they would hand the project over to somebody else. The answer reveals whether they build to be maintained or build to be needed.
5. Require scope, price and timeline in writing before any money changes hands. This is not about distrust; it is the cheapest way to discover you two understood the brief differently.

A good developer will disqualify themselves from something during that conversation. Treat it as a strong signal rather than a lost opportunity.

What is the bus-factor risk with one developer, and how do you manage it?

The bus-factor risk with a single developer is real: one person can get ill, take other work, or simply stop replying, and you have no second line. It is also almost entirely manageable with contractual and operational hygiene rather than with headcount, and most of the damage people attribute to the bus factor was actually caused by poor handover discipline that an agency would not have fixed either.

1. Own the repository from the first commit. It lives in your organisation, with the developer as a collaborator — never the other way around.
2. Every third-party account in your name, with your billing: cloud, app stores, domain registrar, error tracking, analytics. Add the developer to them.
3. Hold the signing keys and provisioning profiles yourself, or at minimum have your own copies. These are the single most common thing to lose.
4. Insist the deploy process is written down and reproducible by someone else. If it only works from one laptop, that is the actual risk.
5. Require documentation as a deliverable, not a favour — a README that gets a new developer from clean checkout to running app.
6. Prefer boring, widely known technology choices. The best insurance against one person leaving is that thousands of people know the stack they used.

Do all six and the worst case becomes an inconvenient handover rather than a lost product. Skip them and the risk is the same whether you hired one person or a company.

What does Percuno take on, and what does it turn down?

Percuno is one engineer, so the filtering matters more than a rate card would. It takes on four kinds of work: building a product from scratch for web, mobile or desktop; taking over a stalled or inherited codebase; delivering a specific feature, integration or migration for a team that cannot get to it; and writing the technical scope for a build before it starts. One client project at a time, and start dates are measured in weeks rather than days.

It is the wrong choice — and worth knowing from this page rather than from an email three weeks in — for a project needing a team of ten, 24/7 on-call cover, a guaranteed response-time SLA, large-enterprise procurement, or staff augmentation to fill a seat on an existing team. Rates are not published, but scope, price and timeline are given in writing before work starts, the client owns the delivered code outright on full payment, and Percuno signs client NDAs.

If that shape fits, the services page has the detail and hello@percuno.com reaches the engineer rather than a sales team. If it does not, an agency is the better answer and this page has done its job.