Three models, and which one fits
The three outsourcing models compared | Fixed-scope project | Dedicated team | Team augmentation |
|---|
| Best for | A defined deliverable with stable requirements | Ongoing product work where the roadmap moves | A specific skills gap in a team you already run |
|---|
| What you buy | An agreed deliverable | Capacity, month by month | Named engineers inside your process |
|---|
| Who directs the work | The vendor, against the agreed scope | Shared: you set priorities, the vendor runs delivery | You, in your own tools and reviews |
|---|
| How it is priced | By the scope; changes priced as changes | By team size and time | By engineer and time |
|---|
| Main risk | Requirements that were not really fixed | Paying for capacity without clear priorities | Onboarding load falls on your own team |
|---|
Fixed-scope project work suits a defined deliverable where the requirements genuinely will not move — a migration, an integration, a rebuild of something that already exists. The scope is agreed, the price follows the scope, and changes are priced as changes rather than absorbed silently.
A dedicated team suits ongoing product development where the roadmap will change; you get capacity rather than a fixed deliverable. Team augmentation suits a gap in an existing team — specific skills, working inside your process and your repositories. Picking the wrong one is the most common reason an outsourcing arrangement turns adversarial.
What you own, stated before anything is written
The code, the infrastructure configuration and the documentation are yours, in your own repositories and your own cloud accounts, from the first commit — not handed over at the end in an archive.
That single arrangement removes most of what makes outsourcing risky. If the engagement ends, you have a running system, its history and its deployment pipeline, and another team can pick it up without an excavation.
Visibility, so the review is not at the end
Every engagement runs the same seven stages, from gathering requirements through planning, design, development, testing and launch, to maintenance — with a clear owner and a clear deliverable at each stage. That applies to a five-week MVP as much as to a multi-quarter build.
The point of the structure is that you see the work as it forms. A specification you first read at handover is not a specification; it is an invoice with paragraphs.
Where outsourcing is the wrong answer
If the requirements exist only in one founder's head and change weekly, a fixed-scope contract will fail and a dedicated team will spend its capacity on rework. If the work is inseparable from daily decisions inside your business, augmentation inside your own process is the honest structure, not a project handed over the wall.
We would rather say this at the scoping call than discover it in month three. A project that should not have been outsourced does not become one by being priced.
