We are an agency. We also put a maximum of three people on any project, usually one or two — and that constraint does more for delivery speed than any process we could put on top of a bigger team.
This is not a humility pitch about being small. It is an argument that most agency staffing is decided by the agency's cost structure rather than by your product, and that you pay for the difference in weeks.
The utilization problem
A large agency carries a large payroll, and a large payroll has to stay billable. Utilization is the number that keeps the lights on, so when a project comes in, the question being answered internally is not "who does this need?" It is "who has room?"
That is how four people end up on a build that needed one. Not malice, not incompetence — arithmetic. The bench has to be busy, and your project is where the room was. Then the four people need a project manager to coordinate them, which is a fifth person, and now there is a standup.
You are paying for all of it, and none of it is your product.
What every extra person actually costs
Communication paths grow as n(n−1)/2. Three people have three. Eight people have twenty-eight. Every one of those paths is a place where a requirement can arrive slightly wrong.
The cost shows up as a game of telephone. You want a button moved and a label changed. On a small team that is a message and twenty minutes. On a staffed-up team it becomes a ticket, which goes to a project manager, who writes it up for a developer who has not seen the screen, who implements what the ticket said rather than what you meant, which comes back in the next demo, and now you are explaining it again.
Nobody did anything wrong. The requirement just crossed four boundaries, and each crossing dropped a little context.
The person in the middle usually cannot check the translation either. A project manager who does not hold the technical detail cannot answer “does that break anything?” — so the question becomes a meeting to find out, and then a second meeting to relay the answer back. Your change is being carried by someone with no way to tell when it has been carried wrong.
That is the real cost of the coordination layer, and it is not the salary. It is the two days.
Small does not mean one
The obvious counter is that a single freelancer has zero communication overhead, and that is true. It also has zero redundancy. One illness, one better offer, one family emergency and the project stops, with nobody who knows the codebase.
Two to three is the shape that works. Enough that more than one person has the system in their head. Few enough that everyone has all of it. Past three, no individual holds the whole picture anymore, and you need process to compensate for what used to be a conversation.
The headcount an MVP needs has gone down
Most agency pricing has not caught up to this yet.
The mechanical half of a build has collapsed. Repo analysis, boilerplate, test scaffolding, migrations, mechanical refactors — the work that used to justify a second and third developer now takes a senior engineer with good tooling a fraction of the time. We use Claude Code and similar tools daily for exactly that.
Be clear about what this does and does not change. It has not made deciding what to build any easier, and it has not replaced the judgment that separates a system you can extend from one you rewrite in month six. If anything it raises the value of the senior person, because reviewing generated work and knowing when it is subtly wrong is a harder skill than writing it was.
What it changes is the arithmetic. The number of people a first build actually requires has dropped. Agency headcount has not dropped with it, and the difference lands on your invoice as people whose main function is to keep each other informed.
Where a big team is genuinely right
This argument has limits, and pretending otherwise would be dishonest.
Once a product is live with real scale, real compliance obligations, and several independent surfaces evolving at once, you need specialists — a dedicated mobile engineer, someone who owns data, someone on infrastructure full-time. That is a real team and it should be staffed like one.
The point is that an MVP is not that. A first version is a small, well-defined problem where the bottleneck is deciding what to build, not typing it. Throwing eight people at a decision problem does not speed it up. It adds seven opinions and a meeting.
What this looks like in practice
- One to three people, never more. Usually the senior engineer who scoped it, plus a second when the work genuinely parallelises.
- No account manager. You talk to the person writing the code, because the translation layer is where cost and misunderstanding come from.
- Hourly against a weekly cap. You see the work land each week and pay for hours actually worked, so a small team's efficiency shows up on your invoice instead of being absorbed as agency margin.
- A button moves in minutes. Not next sprint.
When you are comparing quotes, ask each shop how many people will be on your project and why that number. If the answer is vague, or if it is larger than three for a first build, you have learned something about how that agency is staffed — and you will pay for it in weeks.
If a small senior team is the shape of what you need, that is what we do. See what an app actually costs to build in Charlotte, the MVP development process, or book a call →
