When a project gets approved, the first instinct is usually to ask how many developers it needs. It's the wrong first question. Team size isn't an input you choose — it's an output of what the work actually looks like. Get it wrong in either direction and you pay: too little capacity and the deadline slips, too much and you're funding a coordination problem you didn't have.
This is a separate question from who employs the developers. You can get it wrong with your own staff just as easily as with an agency.
What actually limits delivery speed
On most business software projects the bottleneck isn't typing. It's decisions. How should this exception be handled? Which of the three spreadsheets is the source of truth? Who signs off on the invoice layout?
Those answers come from your side, not the developer's. If a decision takes four days, adding a second developer doesn't help — it creates a second person waiting for it. Before you buy more capacity, check whether the queue is on your side of the table. It very often is.
The coordination cost nobody quotes
Everyone you add has to stay in sync with everyone else. Two people have one relationship to maintain; four have six; eight have twenty-eight. That's not theory, it's the standup that grows to forty minutes and the pull request that sits for two days.
In practice, going from one developer to four does not give you four times the output. Depending on how separable the work is, expect two to three times — and only after a ramp-up period in which everyone is slower, including the person who was already there.
Which leads to the rule that catches people out: adding people to a project that's already late will make it later. If you're behind, cut scope instead. That's usually a conversation about what actually needs to be in version one.
What one experienced developer realistically delivers
Concretely, with clear requirements and a client who answers questions, one senior developer working full time delivers roughly:
- An internal tool or portal — authentication, roles, CRUD, reporting, a couple of integrations: 2–4 months
- An integration between two systems, including error handling, retries and monitoring: 3–8 weeks
- A line-of-business application replacing a serious spreadsheet process: 4–6 months
- A cross-platform app with a backend behind it: 4–7 months
That covers a large share of what mid-sized companies actually commission. The reflex to staff a team of five comes from enterprise habit, not from the size of the work.
When you genuinely need a team
There are real cases. Staff up when:
- The deadline can't move because it's tied to something external — a regulation, a contract, a season — and the scope is already at its minimum
- The work splits cleanly into parts with few shared touchpoints, so parallel work doesn't collide
- It needs skills one person can't credibly hold — embedded firmware plus a data platform plus a native app is three careers, not three tasks
- It runs 24/7 with an on-call rota, which needs more than one person by definition
Notice that "the project is important" isn't on the list. Important and large aren't the same thing.
The shape most people miss
The useful middle option is one developer who owns the whole thing, with specialists brought in for short, specific pieces: a designer for two weeks up front, a security review before launch, a database specialist for a day when a query plan goes bad. You get the expertise without the standing coordination cost, and one person still holds the full picture — which is worth more than it sounds when something breaks at 4pm.
What each option costs
- One senior contractor: €90–€130 per hour, roughly €13,000–€19,000 per month full time
- Agency team of four (two developers, part-time lead, part-time designer or QA): €45,000–€75,000 per month
- In-house hire: €70,000–€110,000 per year fully loaded, plus three to six months of recruiting before anything ships
Compare those against the delivery estimates above, not against each other. A team that delivers in three months what one person delivers in five has cost you roughly three times as much to buy two months.
The honest downside of one person
A single developer is a single point of failure. Illness, a bus, a better offer. The mitigation isn't hiring redundancy you don't otherwise need — it's making the work transferable: your own repository from day one, a documented setup, standard technology choices, no unexplained deployment magic. If a competent developer can pick it up in a week, the risk is manageable. If they can't, the problem is the handover, not the headcount — see avoiding vendor lock-in.
Sizing a project?
If you're weighing a quote from a team against a quote from one person, the honest comparison isn't the day rate — it's what each one delivers, by when, and what happens afterwards. Send me the scope and I'll tell you straight whether it's a one-person job.