Skip to content
Eterna

Process · 30 Jul 2026 · 5 min read

Why we keep project teams small

Clients sometimes ask whether a bigger team would be faster. In our experience it is usually slower. This is why smallness is a rule for us, not a constraint.

By Nikola Aleksov, Eterna

A small team working together around a wooden table

Article

Every Eterna project is staffed by a small team, usually three people, and a founder is one of them. Clients sometimes ask whether a bigger team would be faster. In our experience it is usually slower, and this post explains why we have made small project teams a rule rather than a constraint.

Communication cost is quadratic

Three people have three lines of communication. Eight people have twenty-eight. Every one of those lines is a place where context is lost, a decision is made twice or a bug is assumed to be someone else's. Fred Brooks wrote this down in 1975 and the industry has been rediscovering it every few years since.

Ownership is not divisible

On a small team, one person holds the whole system in their head. They know why the pricing module is structured the way it is, and they know what will break if the schema changes. That knowledge can be shared with a second and third person. It cannot be shared with a tenth without turning into documentation nobody reads.

Small teams say no

A team of twelve has to be kept busy. That pressure shows up as scope creep, over-engineering and features that exist because someone had capacity that week. A team of three has the opposite problem: every feature has to earn its place, because building it means not building something else. Clients feel this as a bias towards simple solutions.

What we give up

There are things a three-person project team cannot do. We do not take on projects that need forty engineers, and we do not promise round-the-clock coverage across every time zone. We run a limited number of projects at once, which means there is sometimes a wait. We think that is a fair trade for a team where the person who scoped your project is the person debugging it at launch.

Speed on a software project comes from fewer decisions, not from more hands.

How it works in practice

Each project has one engineer who owns the codebase, one who reviews everything and shares the load, and a founder on scoping and operations. You get a shared channel with all three. Decisions happen in hours because there is nobody to escalate to.

Next step

Have a project in mind?

Tell us what you are trying to build. We reply within one business day, usually with a few questions and a rough sense of scope.