Nine women cannot give birth in one month.
You can staff up bigger teams to accomplish bigger goals, but this is far from linearly scalable, with different categories of problems showing up in larger organisations.
The second reason it doesn't work is that splitting the app into separate parts that can be worked on in parallel, is essentially determining the software architecture. If you haven't sorted that out then the different parts will get built, not work together, and then there will be a sh*%storm of blaming each other for why they don't work together.
There are cases where new devs can help, but if you don't have the overall architecture sorted out yet, then they will not, and if you do then there is a finite pace at which new devs can be integrated and brought up to speed.
The old analogy to pregnancy is, in fact, spot on.
Piling devs onto a project is counterproductive for fundamental communications reasons.
The three chief alternatives are:
- Highly modularise the project and treat those modules as independent projects.
- Launch multiple projects which compete against one another for ultimate launch. Again, treat those as independent projects.
- Buy competing projects. This is a variant of the second option. The competing projects are inherently independent.
Both approaches reduce communications overhead. The result isn't faster production, but rather risk mitigation and diversification over a larger set of investments. Both approaches also work best for an organisation which already has a large engineering capacity.