It takes one person to change a lightbulb. Maybe a second person to hold the ladder. Any more people assigned to the job will slow it down.
Go slow
Assigning too many people to a project is a pernicious way of slowing it down. The number of people on a project increase communication and Conway's Law tells us this directly affect complexity.
There are many products being developed and maintained by huge teams, but this requires huge investments in processes and architecture.
Processes like tests and reviews optimize the flow of communication. Anyone who would be misaligned with the vision that is encoded into processes will be stopped and realigned before they can introduce significant chaos.
Software architecture tries to maintain the relation between complexity and time as linear as possible. It attempts to isolate complexity behind boundaries and abstractions to benefit from information hiding.
Break things
The original "Go fast and break things" motto was meant not to let that one customer still using Windows XP from tying you down to .NET 4.0 (I still know of a case like that still in 2022!). It was never meant to let the software degrade into a big ball of mud.
But I'm subverting it for the catchy title. I mean "break things" as in the bugs that come from the increase in complexity. Even the most experienced developers with great processes and architecture will produce more bugs as complexity increases.
Ask developers on a 30 people or more project where the bugs come from and most will tell you that their services are well designed. It's the upstream team that is misusing their API and the downstream team that is putting constraints on their API that are preventing value delivery.
This is perfectly normal, especially when developing interdependent green field components in parallel. The contracts on those APIs need to be negotiated and no amount of overthinking can bypass that experimentation phase for any significantly complex problem. That negotiation builds a common vocabulary and understanding that lets people develop the systems-level thinking required to solve real world problems. I hope to write about how I believe linguistic determinism applies to software design someday...
For the functional aspects of the APIs, the negotiation is quite straightforward. It's the non-functional aspects that slip under the radar and into production issues. Performance/Scalability, error handling, what fields are sensitive data and should not be written in trace logs, etc.
Team sizing
Resource allocation is a complex topic affected by hiring/retention constraints from below as well as strategic initiatives and ROI vs cost of opportunity considerations from above. It is an incredibly complex problem, and every situation is unique.
Yet there are patterns to discern. I've seen many teams of a 1 to 3 people start or take over a project and scale up gradually as they gained new customers and maintain their velocity with great success. I've also seen a few instances of a new 10 or more people team being formed to work on a project and stand still for over a year, hardly delivering any value.