There is this misconception that software development can be ultra lean and only really need a team of few handful of people if they're just sufficiently capabl

There is this misconception that software development can be ultra lean and only really need a team of few handful of people if they're just sufficiently capable. It's knowledge work that is almost always in the complex domain, and as such it's far from simple. In fact it's the domain of unknown unknowns. So to have a product with millions of users with an online attack vector, that takes security and uptime serious, you need the following lead roles as a minimum: * Architect * Security * Test * Agile * Developer * Operation * Owner * UX Security, Test, Agile, Operation, Owner are at the very least full time posistions in their own right for a single service, then you need to add developers. Add requirements for new documentation and maintenance of old. You probably need some support roles too. An app with millions of users are likely to have multiple teams that have a subset of the full application. For every feature you want to develop or any significant refactorings, you need to involve at least architect, security, test and operations. My experience is that teams around 8-10 people can be really productive and run a service. If you really want to accelerate and be best in class you assign teams to specific parts of the service that makes sense. Could be signup, search, chat, ect. Then you probably want teams for analytics, ads and marketing, legal and before you know it, you have 50+ people working directly on a "self-standing product". All that said, if the code base is crap, and the organization of the employees are similar it's highly likely that alone is responsible for creating the additional workload compared to a better codebase and organizational structure.