An in-house team delivers the most control. The engineers absorb your domain over time, and that knowledge sits in the building. The price is time and rigidity: filling a senior role routinely takes several months, getting someone productive adds several more weeks, and the cost carries on through the quiet quarters.
Handing a project to a vendor implies the vendor owns delivery: they staff the team, the partner manages the process, and they absorb the risk of missing the date. The model works when the outcome can be described and you have an available product owner. It works badly when nobody on your side owns the product, as an external team will not guess what the business wants.
Team extension falls in the middle: you add engineers while keeping responsibility for delivery in-house. The main advantage is speed — the right specialist is often available far sooner than a new hire ngrx developers — and it scales down as easily as it scales up. The trade-off remains that your own leads must have time for code review and planning. Without that, you are paying for effort with no owner.
In the real world, these models are combined. One durable pattern puts the architecture and the core domain inside the company, while an outside vendor takes on the parts that are bounded difference between rest and graphql specifiable. The rule is simple enough: keep the parts that are hard to re-learn, and outsource what is well understood.
Three questions resolve most of these debates. Start here: is the system central to how you make money, or a supporting tool? Then: for how long does the work continue — months or years? Finally: who answers the phone at two in the morning when it breaks? Work through them with real answers and the model usually chooses itself.