Building your own team buys you the most control. The developers learn your domain over time, and that knowledge sits in the building. The software development cost comes in the form of slow hiring and fixed overhead: hiring well routinely takes several months, onboarding takes several more weeks, and the payroll keeps running regardless of workload.
Handing a project to a vendor implies an external team owns the outcome: the partner staffs the project, they manage the process, and they carry the delivery risk. This fits well when the work is a defined project and there is a decision maker with time for it. It fails when there is no one to answer questions, as a vendor is not able to guess what the business wants.
Team extension falls in the middle: you add engineers and keep the management on your side. It moves quickly — a suitable engineer is often available almost immediately — and it winds down as quickly as it ramped up. The catch is that your technical leaders have to have time for code review and planning. Without that, the result is paying hourly for uncoordinated work.
In the real world, companies blend them. One durable pattern holds architecture, livewire developer product decisions and core domain code inside the company, while an outside vendor covers peaks, well-defined modules or platform work. The principle is easy to state: retain what defines your product, and delegate the well-trodden work.
A few questions generally decide the matter. First: is the system a core competitive asset, or a supporting tool? Then: for how long will you need this capacity — one project or a permanent roadmap? Third: who owns it once the vendor leaves? Answer these three honestly and the model usually chooses itself.