Building your own team gives you the most control. The people learn your customers and your data model in a way no external team will match, and this context sits with you. The catch shows up as time and rigidity: recruiting a strong engineer takes months, onboarding adds several more weeks, and the payroll carries on whether the roadmap is full or empty.
Handing a project to a vendor implies an external team owns the outcome: they staff the project, they manage the process, and they carry the delivery risk. The model works when the outcome can be described and your side has someone who can make decisions quickly. It breaks down when the requirements change weekly, since an external team cannot fill that gap for you.
Team extension falls in the middle: you add engineers while keeping the management yourself. It moves quickly — a suitable engineer can start far sooner than a new hire vuex programmer — and the commitment ends when the work does. The catch remains that your engineering managers must have the bandwidth to manage them. If that capacity is missing, the result is paying for effort with no owner.
Most of the time, these models are combined. A frequent arrangement keeps the critical decisions and the core system in-house, while an external team takes on peaks, well-defined modules or platform work. The line is simple enough: hold on to the parts that are hard to re-learn, and contract out the well-trodden work.
A few questions resolve most of these debates. Start here: is what you are building a core competitive asset, or a cost centre? Then: for how long will you need this capacity — a quarter or a decade? Finally: angular development company who owns it once the vendor leaves? Work through them with real answers and the model is normally clear.