1. the improvements will probably come at roughly the logarithm of the number of people added at best (and, you can do worse without discipline and/or with a dysfunctional organization, possibly even negative), and

2. after their ramp-up period, like 6-9 months, during which each person might contribute a small negative load in mistakes, draining existing talent's time with questions, etc., and

3. you prioritize and value fixing bugs over adding new features, and

4. you probably want to structure those engineers in ways where they can contribute off of the critical path, like QA, dedicated to straight bug fixing, etc., and

5. You probably need an almost "microkernel" like team for very large projects--because the communication overhead grows as n^2, you need a small core, and ways to scale and build without growing the communication overhead--teams working on well defined and isolated subsystems off core, various "modules" that interface with the "microkernel core team" without imposing n^2 communication overhead between everyone working it, without breaking the product or making serious mistakes from not having n^2 connections

just thoughts, really. my intuition is: do everything right, and you can get log(added people) productivity increase time delayed (with a short term dip as those people get up to speed), up to, unfortunately, negative gain if you do much wrong

I don't know how successful this would be, but they could also start building and selling more apps/programs but perhaps this could be seen as anti competitive.