You have decided to add offshore engineering capacity. Now you have to pick an engagement model, and the ODC vs dedicated team vs staff augmentation choice is harder than it needs to be because vendors use the three names loosely. We do it too. The headline on our own offshore development center page promises a “dedicated team”.
This article defines the three models by what happens in practice and shows where the labels overlap. It then gives a decision rule built on four things you already know: how long you need the capacity, how many people, how much management time you have, and how stable the scope is. We are a vendor in Hanoi and we sell all three, so we have no reason to push you toward one of them. We do care that you land in the one that fits, because a model that doesn’t fit is hard to rescue with extra effort later.
If you are still choosing between hiring people and buying a finished deliverable, start with our earlier post on staff augmentation vs full outsourcing. This one assumes you want people and are deciding how they should be organized.
The three models, defined by seven questions
Set the label on the proposal aside and ask these seven questions. The answers tell you which model you are buying.
| Question | Staff augmentation | Dedicated team | Offshore development center (ODC) |
|---|---|---|---|
| Who employs the engineers? | The vendor | The vendor | The vendor |
| Who manages them day to day? | Your engineering lead, who assigns tasks and reviews the code | The vendor’s PM or tech lead runs the sprint. You steer through the backlog. | Vendor-side leads run each team. You agree on roadmap and headcount with a delivery manager. |
| Who owns the backlog? | You, down to the individual ticket | Your product owner orders it. The team breaks it down. | Your product owner for each product the center works on |
| Where does knowledge accumulate? | In your team and your documents. The person’s own context leaves with them. | In the team as a unit, so it survives one person leaving | In the center: several teams plus shared onboarding material, environments and working habits |
| What are you paying for? | The time of specific individuals | One team’s monthly capacity, including its lead and QA | Standing capacity and the structure around it: leads, QA, hiring, onboarding |
| How do you scale down? | Seat by seat, on the notice in the contract | By shrinking the team. Below a certain size it stops working as a team. | Through planned headcount changes. Of the three, this one is slowest to reduce. |
| When does it end? | When the gap closes or your own hire arrives | When the product ships or moves into maintenance | It has no planned end. It ends through a wind-down or a transfer. |
The first row is the same in all three columns. In none of these models do you become the employer, so payroll, benefits, office, equipment and local labor law stay with the vendor. What changes from left to right is how much of the management the vendor carries and how long the arrangement is built to last.
ODC vs dedicated team: where the names blur
A dedicated software development team and an ODC share a working model. The engineers work only on your product, your product owner sets priorities, and the vendor runs delivery. They differ in scale and permanence. A dedicated team is one team built around one product or release. An ODC is the standing structure that holds one or more of those teams and is expected to outlive any single release.
That is why the same proposal can carry either name. A few translations help.
| What the proposal says | What it can mean | The question that settles it |
|---|---|---|
| “Dedicated team” | A full team with its own PM and QA, or two developers you manage yourself | Who assigns work to each engineer every morning? |
| “ODC” or “ODC model” | A multi-team center with its own leads, or a single small team with a bigger name | What exists beyond the engineers: leads, QA, onboarding, security setup? |
| “Staff augmentation” | Individuals inside your team, with or without a vendor-side manager watching performance | Who do I call when someone is out sick or not working out? |
| “Extended team” or “managed team” | Anything from augmentation to a dedicated team | Who is accountable when a sprint goal is missed? |
| “Outsourcing” | Often a fixed-scope project, which is a different purchase | Am I buying a deliverable or capacity? |
Ask us these directly when we talk. We would rather agree on who does what than on what to call it.
A decision rule for choosing between the three
Four inputs decide the model. Take them in this order, because the first one rules options out fastest.
1. Management capacity on your side. Count the people who can direct engineers every day: break work into tickets, answer questions within hours, review pull requests. If the count is zero, staff augmentation is off the table, however good it looks on paper. Augmented engineers without direction sit idle, and you pay for the idle time.
2. Scope stability. If the scope is fixed and written down, none of these three is the right purchase. Buy a project with a defined deliverable through custom software development. All three models here assume the scope will move and that you want to change priorities without a change request.
3. Duration. If you can name an end date, such as a release, a migration or a hiring gap, you want staff augmentation or a dedicated team. If you can’t, because the product will keep needing engineers, you want a dedicated team that is allowed to grow, set up so it can become an ODC.
4. Team size. The Scrum Guide puts a working team at “typically 10 or fewer people”. It says larger groups should reorganize into several teams that share one product goal, one backlog and one product owner. That threshold makes a useful dividing line. Up to one team, a dedicated team is enough. Once you need more than one, somebody has to coordinate across teams, keep practices consistent and plan hiring. An ODC adds that coordinating layer.
Put together:
| Your situation | Model that fits |
|---|---|
| A tech lead with time, a specific skill gap and an end date | Staff augmentation |
| A product owner but no spare engineering management, one product, a moving scope | Dedicated team |
| No end date, or more than one team, and a product owner you can commit | ODC |
| Neither a product owner nor an engineering lead available | None of the three. Buy a project, or free up a product owner first. |
Buyers tend to skip the last row. Every model here needs somebody on your side. The models differ in which role they need and how many hours it takes.
The hidden management cost of each model
A quote shows the vendor’s fee. It doesn’t show what the model costs your own people.
Staff augmentation costs you engineering management
Your lead onboards each person, slices the work, reviews it and handles the daily questions. That load grows with every seat you add, and it lands on the people you were trying to relieve. A second cost shows up later. When an augmented engineer rolls off, their understanding of your system goes with them unless you made documentation part of the job.
A dedicated team costs you a product owner
The vendor’s PM takes over task assignment, reviews and people issues. Deciding what matters stays with you. The Scrum Guide is blunt about this role: the product owner is accountable for ordering the backlog and “is one person, not a committee”. Without that person the team stays busy and drifts. Plan for sprint reviews, acceptance of finished work and a steady supply of decisions.
An ODC costs you governance
You need a product owner for each product, plus someone senior who agrees headcount plans, security requirements and escalations with the vendor’s delivery manager. Deloitte’s 2024 Global Outsourcing Survey, which drew on more than 500 executives, reports that organizations run into trouble as their sourcing options multiply, and it ties that to the maturity of their internal governance and management capabilities. A capable offshore team still stalls when nobody on the client side has the authority to steer it.
The in-house comparison has hidden costs too
When you set any of these models against hiring locally, compare whole costs on both sides. US Bureau of Labor Statistics data for June 2026 shows that for full-time private-industry workers, wages and salaries made up 68.5% of employer compensation costs and benefits the other 31.5%. That is market data across all occupations. It is not a software figure and it is not a price. A salary understates the cost of an in-house hire in the same way a vendor fee understates the cost of an offshore model once your own management hours are counted. We go through what drives an offshore fee in our guide to an offshore development center in Vietnam.
Worked examples from our published case studies
Our case study pages print team sizes and durations. They don’t print the contract type, so read these as team shapes and not as contract examples. Each one maps onto the decision rule differently.
Three people, one bounded job
Draco Help, a Romanian safety app with a panic button, was built on Vue Native, a framework its creators had stopped supporting. A MOHA team of three moved it to React Native. The size and the single skill look like staff augmentation. What decides it is the first input in the rule: can someone on the client side direct mobile engineers every day? If so, augmentation is the lighter setup. If the client wants the vendor to analyze the old codebase and plan the migration, as happened here, a small managed team fits better.
Six roles, one product
The COMY language learning LMS has the shape of a dedicated team: a PM, two back-end developers, a front-end developer, a QA engineer and a UI/UX designer for about five to six months. With a PM inside the team, a buyer in this position doesn’t need an engineering manager. They need a product owner who knows the business the software serves.
Fifteen people for three months
The marketplace for high-value machines, built for a Japanese client on .NET, React and React Native, lists a team of 15 and a three-month duration. Fifteen people is more than one team by the Scrum Guide’s measure, yet three months is too short to justify a standing center. A large team doesn’t make an ODC unless the need is also long-lived. A short, large effort like this runs better as a dedicated team split into sub-teams under one delivery lead.
Thirty people
The application auto-generation system for a Japanese retail chain lists a team of 30. It covers a web admin where staff pick templates, AWS storage for source code and app profiles, and Azure pipelines that build the store apps. At 30, no single tech lead can direct everyone. The work has to be divided into teams with their own leads, a shared QA practice and a plan for bringing new people in. Whatever the contract calls it, that is the structure of an ODC, and the client has to supply governance to match.
Moving between models as the product matures
The model you start with is rarely the one you keep. We see three transitions.
From staff augmentation to a dedicated team, the signal is your own lead becoming the bottleneck. Reviews queue up, tickets aren’t ready when engineers need them, and adding another seat makes things slower. Move task management to a vendor-side lead and keep the same engineers.
From a dedicated team to an ODC, the signal is a second product, a second team, or a roadmap that now runs past the release the team was formed for. You add a delivery manager above the team leads, shared QA and a hiring plan. The existing team becomes the first team in the center.
The third move goes the other way. Products reach maintenance, and a center can shrink back to one team that keeps the system running. Some companies take the team in-house instead. The same Deloitte survey reports that insourcing is rising and that global in-house centers are regaining momentum, with many organizations using build, operate, transform and transfer models to set them up.
A few habits keep these moves cheap. Keep the code in repositories you own from the first commit. Make written documentation part of “done”. When the model changes, change the management layer and keep the engineers, because they hold the context.
Contract points per model: questions to ask us
The same clauses matter in every model, but they carry different weight in each. Bring these to a conversation with us and we will answer them for your case.
| Clause | Staff augmentation | Dedicated team | ODC |
|---|---|---|---|
| IP assignment | Does each individual’s work transfer to us under the agreement, and is each person bound by confidentiality? | Does assignment cover everything the team produces, including designs, test suites and documentation? | Does it also cover the center’s shared assets, such as build pipelines, internal tools and onboarding material? |
| Notice | How much notice ends one seat, and is there a minimum term per person? | How much notice do you need to resize the team, and what is the smallest team you will run? | How are headcount changes planned, and what does a full wind-down or transfer involve? |
| Replacement | If a person leaves, what happens to the seat and who covers the handover time? | Who decides that a team member should be replaced, and how is continuity kept inside the team? | How do you handle attrition across the center, and who backs up each lead? |
| Exit | What do we receive when the person rolls off? | What does a handover to another team include? | Can the team move to our own entity later, and on what terms? |
What changes when the team is in Vietnam
Time zone shifts the balance between the models. Hanoi is on GMT+7 all year. Singapore is an hour ahead and Sydney three or four depending on the season, so buyers there can manage augmented engineers through a normal working day. For them, IT staff augmentation in Vietnam is a practical choice.
From the US the overlap is a thin slice at the edge of the day. Staff augmentation depends on fast answers from your lead, so it suffers most. A dedicated team or an ODC with its lead in Hanoi absorbs the gap, because the person unblocking the engineers sits in the same office. US buyers who still want augmentation should plan one fixed daily call and written handoffs. Our buyer’s guide to software outsourcing in Vietnam lists the overlap by market.
FAQ
Is an ODC the same as a dedicated team?
The working model is the same: engineers who work only on your product, priorities set by you, delivery run by the vendor. An ODC is the larger and more permanent form. It holds more than one team or is set up to, has its own leads and shared practices, and has no planned end date.
Which model costs the least?
It depends on what you count. Staff augmentation is the smallest commitment and puts the largest demand on your own managers. An ODC carries the most structure and asks the least daily effort from you per engineer. Add the vendor fee and your own people’s hours before you compare. Tell us your situation and we will talk through what each model would involve.
Can we start with staff augmentation and convert later?
Yes. It works best when the same engineers stay and only the management changes. Ask us how a conversion would be handled before you sign the first agreement, so the terms allow it.
How is staff augmentation different from outsourcing?
In staff augmentation you manage the people and own the outcome. In project outsourcing the vendor owns delivery of a defined scope. Dedicated teams and ODCs sit between the two. We cover that comparison in staff augmentation vs full outsourcing.
Talk to us about your team
If you know roughly how many people you need, for how long, and who on your side will direct the work, you have enough to choose. We run offshore development centers and provide staff augmentation from Hanoi. Contact us to discuss which model fits your product.
