The conditions matter. But for a typical custom software project, which is usually a few months, one domain, one codebase, a small team almost always moves faster than a large one. Not because of talent, but because of math.
The communication overhead problem
If you have three engineers, any two of them can sync in five minutes. They share context naturally because the project is small enough that everyone knows all of it. Decisions happen in a Slack thread. If two engineers disagree about an approach, they hash it out in half an hour and move.
With ten engineers, the number of potential communication channels is 45. Not all of them are active, but the ones that are require management. Somebody needs to know who decided what and why. Meetings exist to align people on things that a smaller team would just know. Coordination becomes a job in itself.
Brooks' Law says that adding people to a late software project makes it later. The mechanism is straightforward: new people need to be brought up to speed, and bringing them up to speed takes time from the people who are already working. On a small project, that cost never gets amortized enough to justify the new headcount.
Decision speed
Small teams decide faster. There's no approval chain. When a design question comes up mid-build, the engineers and the client can resolve it in the same day. On a large team, that question might sit in a backlog, go through a design review, come back with comments, and get resolved two weeks later.
That lag is invisible in individual instances. It compounds across a project. A team that makes decisions in hours rather than days ships noticeably faster over a three-month engagement, even if every individual decision is identical.
The tradeoffs are real
A small team has a higher bus factor. If one person is out sick, velocity drops visibly. You can't specialize as much, which means everyone needs to be a generalist to some degree. Deep specialization is a luxury that requires more headcount to justify.
There are also projects that genuinely need more people. Very large builds with separate, parallel workstreams that can't be coordinated by a small group. Systems where the infrastructure, backend, and frontend are truly independent and all need to move simultaneously. Those exist. Most custom software projects are not them.
What this means in practice
When we take on a project, you work with the same people throughout. Nobody hands your project to a junior after the kickoff call. The engineers who talk to you about requirements are the engineers who write the code. That's not a selling point for its own sake. It's how the communication efficiency of a small team actually works. The context doesn't need to be transferred because it was never split in the first place.