There's a number most software leaders quietly know but don't discuss: the point at which adding people to a team stops making the team faster. It's smaller than you think. That number is why QuantumLoop is a small studio on purpose, and why we'll likely stay that way.
The math that agencies don't want you to do
When you add a developer to a team, you get their output, minus the overhead they create for everyone else. Overhead is real: onboarding time, context they don't have, code reviews they need, questions they ask, status meetings they attend. For most team sizes, that overhead is modest. Beyond a certain point, it swamps the contribution.
Brooks wrote about this in 1975. Half a century later, we're still adding people to late projects and wondering why they're later. The relationship between team size and output isn't linear and it isn't even monotonic. It's a curve with a peak, and for most products we've built, that peak sits somewhere between three and six people.
What senior actually means
"Small, senior teams" is a phrase that gets abused. It doesn't mean "expensive people with fancy job titles." It means people who:
- Can hold a whole product in their head, the data model, the user flows, the failure modes, and reason about changes as a coherent system
- Know when to ask permission and when to ship; the difference between the two isn't always obvious
- Have been burned enough times to have earned their opinions about abstraction, testing, and rewrites
- Care about the product, not just the code they touch
- Can disagree productively, a senior team without real dissent is just a dressed-up echo chamber
You can't fake this by stapling "Senior" onto a title. Either someone has shipped real software through real production fires, or they haven't. The difference shows up in week one.
What you actually get with four seniors
A team of four seniors, working in lockstep on a product they all understand, will out-ship a team of twelve with three seniors and nine juniors. It's not close.
Here's what that looks like in practice:
- No handoffs. The person designing the API is the person shipping the UI that consumes it. The feedback loop between intent and implementation collapses from days to minutes.
- Decisions don't require meetings. When you have four people who've all earned the right to make calls, you make them in Slack or on a 10-minute call. You don't need a design review board.
- Every line of code has an owner who cares. Bugs get fixed because someone feels them personally, not because a ticket got assigned in a triage meeting next Tuesday.
- Context doesn't evaporate over the weekend. Small teams keep the whole mental model warm. Large teams paper over the lost context with documentation, but documentation decays faster than code does.
What this means for how we scope
When a prospective client asks us for a team of ten to rebuild their platform, we often say no. Not because we can't staff it, we can, but because the shape of the engagement is wrong. What they usually need is four of us for six months, not ten of us for three. The calendar looks similar on paper. The product that comes out the other end is not.
We'd rather ship a tight v1 and then grow the team into v2 once the product earns it, than start with twelve people and waste four months figuring out how to coordinate them.
What this means for how we price
Fewer, more senior people cost more per hour. They also burn fewer hours. The mistake is comparing hourly rates instead of comparing delivered software. A team that ships a working product in eight weeks at $200/hour is dramatically cheaper than a team that ships a buggy product in twenty weeks at $120/hour, and that's before you count the months of rework.
Price per outcome, not price per hour. Studios that optimize for throughput learn this the hard way. We price projects to incentivize finishing, not billing.
The counterargument, and why we think it's wrong
The standard argument against small teams is "they can't scale." This gets trotted out as if scale is a virtue in itself. It isn't. Most software needs to be usefully done, not infinitely scalable. Scale is a problem you buy by succeeding, and when you have that problem, you build the team the product needs. You don't hire the team first and hope a product emerges to justify them.
The companies doing the most interesting software work today, the indie hackers, the infrastructure teams inside major platforms, the research labs pushing AI forward, run on small, senior teams. The twelve-person pod with two leads and a project manager is a 2010s artifact. It persists because it's easy to budget, not because it's how great software gets made.
Software is not made by throwing people at it. It is made by a small number of people who care, who understand, and who are allowed to finish.
So what does this mean for you?
If you're choosing a partner for a build, ask them how many people will actually touch your code. Ask them who the seniors are. Ask them what happens when a senior is on vacation. Ask them how many active projects they're running at once. The answers tell you more than any pitch deck.
We keep a small number of active engagements on purpose. It's why our work looks coherent from the outside. It's also why we say no more often than we say yes. If that's a tradeoff you're willing to make, we should probably talk.
Curious what a small, senior team looks like on your problem? Tell us about it.