A common question I get from founders is how to structure their development team.

Specifically, how many developers they should have and what their roles should be.

While it may seem cheaper and “safer” to find one great developer, I always recommend that they have two or more.

This is because:

• you have redundancy if one developer leaves, or is on leave
• you can have “urgency-based queues”, i.e. one developer is focused on feature work, while the other can respond to more urgent issues like bug fixes and small quality of life tweaks
• the work capacity can stay more constant because you are not overloading a single developer
• who will eventually burn out and/or need extended time off
• you can hire developers with slightly different specialisations, e.g. one who’s great at user interfaces and one who’s great at complex workflow. They’ll both be able to do all the work, but they’ll have a natural flair for certain types of work which can be a benefit.
• it forces you to adopt a more scalable development process early on, which avoids some of the growing pains you’d experience when starting with a single developer.

Why not three or more?

Every team member you add, adds complexity. More communication channels (see Brook’s Law), more people to keep in the know, more chances of misunderstanding each other’s work and introducing bugs, etc.

Obviously this is also an issue with two vs one developers but it is a necessary trade-off.

Depending on the size of your project, three or more may be necessary. Just keep in mind it will require more management overhead and focus on process.

While adding more developers can increase complexity, a team of two strikes a balance between efficiency and manageability, setting the foundation for sustainable growth.