Dedicated team, staff augmentation, or fixed-scope project?
If your requirements are written down and unlikely to change, do not buy a dedicated team. A fixed-scope project will cost less and transfer the delivery risk away from you, and paying a monthly team rate to build a specification that already exists is the most common way this money gets wasted. Dedicated teams earn their keep on work where the requirements will move, and knowing which situation you are in is the whole decision.
What actually differs between the three models?
Who decides what gets built next, and who absorbs the cost when that decision changes. Everything else, including where people sit and how invoices are worded, follows from those two questions.
In a fixed-scope project the supplier decides how, you decided what, and the supplier absorbs overrun inside the agreed scope. In staff augmentation you decide everything and absorb everything, because you are buying hands to place inside your own process. A dedicated team sits between: you set direction and priorities, the supplier owns team composition, delivery practice and the replacement of anyone who leaves.
The practical test is to ask who writes the tickets. If your people write them, you want augmentation or a dedicated team. If you would rather hand over an outcome and receive a system, you want a fixed-scope project, and the fact that you cannot write the tickets is a warning that the scope is not as fixed as the contract will claim.
When is staff augmentation the right answer?
When you already have a functioning engineering organisation and a specific shortage. You have a tech lead, a code review culture, a deployment pipeline and a backlog, and what you lack is three more people who can work inside all of that. Augmentation drops individuals into a machine that already runs.
It fails in the opposite case. Placing two contractors into a company with no senior engineer produces work nobody can review, decisions nobody can arbitrate, and a codebase whose conventions are whatever the last contractor preferred. The augmentation model quietly assumes you supply the engineering leadership, and companies that do not have it discover this three months in.
The other limit is duration. Augmentation is priced and structured for a known gap. If you are still extending the same contractors after a year, you are running a dedicated team without the parts that make one work, notably a team lead who is accountable for the whole and a supplier obligation to backfill departures.
| Fixed-scope project | Staff augmentation | Dedicated team | |
|---|---|---|---|
| Who defines the work | Defined upfront, in the contract | You, ticket by ticket | You set priorities, team plans delivery |
| Who owns delivery risk | Supplier, within scope | You, entirely | Shared: supplier owns capability, you own direction |
| Cost of a change of mind | High, triggers a change request | Low | Low |
| Needs your own engineering leadership | No | Yes | Helpful, not required |
| Who replaces someone who leaves | Supplier, invisibly | You reopen a search | Supplier, with handover as an obligation |
| Sensible minimum duration | Length of the scope | Weeks to months | Six months and up |
When does a fixed-scope project genuinely work?
When the unknowns are in the build rather than in the requirement. Migrating a known system to a known target, integrating with a documented API, rebuilding an existing product on a new stack: the destination is describable, so it can be priced, and the supplier can reasonably carry the risk of getting there.
It stops working the moment the answer to what gets built depends on what users do with the earlier version. Anything discovery-shaped, anything where the second month should be informed by the first, will be dragged out of shape by a fixed scope, because both parties now have a financial interest in pretending the original plan was right.
The failure mode is recognisable and expensive. Change requests become the real project, the relationship becomes adversarial around what was in scope, and the supplier begins optimising for defensible delivery rather than useful delivery. If you can see that coming during the sales process, buy a different model instead of a tighter specification.
What does a dedicated team actually get you?
Continuity of context, which is the only thing in this comparison that compounds. A team that has been in your codebase for a year estimates accurately, knows which module is fragile, and can tell you that the feature you asked for will conflict with something you shipped in March. That knowledge is worth more than the hourly rate difference and it is exactly what you lose every time you re-tender.
You also get a capability contract rather than a person contract. The supplier is obliged to keep the team staffed at the agreed shape, which means holidays, illness and resignations become their problem rather than a hole in your roadmap. This is the single clearest difference from augmentation and it is worth checking is written down rather than assumed.
What you do not get, and should not expect, is a team that runs itself with no input. A dedicated team without a product owner on your side will build competently in a direction nobody chose. If you cannot name the person who will decide priorities weekly, fix that before signing anything.
Can you start with one model and change later?
Yes, and the common sequence works well: a small fixed-scope piece to test whether the supplier is any good, then a dedicated team once you trust them. A discovery phase or a single well-bounded module is a cheap, honest audition, and it gives both sides a real estimate for the larger engagement rather than a sales one.
The reverse sequence is harder. Converting a dedicated team into a fixed-scope arrangement usually means the relationship is being wound down, and the pricing rarely favours you, because the supplier is now quoting a fixed price for work in a codebase you are about to take somewhere else.
Whichever way you go, the transition is the moment to check that the contract covers repositories, credentials and documentation rather than only headcount. Model changes are when handover gaps surface, and they are much cheaper to fix before the change than after it.
How do you decide this afternoon?
Answer three questions honestly and the model chooses itself. First: could you write the acceptance criteria for everything you want, today, without seeing anything working? If yes, fixed scope is on the table. Second: do you have a senior engineer who will review the work and arbitrate technical decisions? If yes, augmentation is on the table. Third: will the priorities in month four be decided by what you learn in months one to three? If yes, only a dedicated team fits.
Most companies answer no, no and yes, which is why dedicated teams exist as a category at all. The answer is not a compliment to the model; it reflects that most software work is discovery in a costume.
If your answers are mixed, split the work rather than the model. A fixed-scope integration running alongside a dedicated product team is a normal arrangement and is much easier to manage than one contract stretched to cover both.
Common questions
- What is the difference between a dedicated development team and staff augmentation?
- Staff augmentation places individual engineers inside your existing process, so you supply the leadership, the code review and the delivery practice, and you carry all the risk. A dedicated team is contracted as a unit with its own lead, and the supplier is obliged to keep it staffed, handle departures and own delivery practice while you set priorities. Augmentation suits a known short-term gap; a dedicated team suits long-running work where requirements will change.
- When should I use a fixed-price project instead of a team?
- When the destination is describable before work starts and the unknowns are in the build rather than the requirement. Migrations, documented integrations and rebuilds of existing systems price well and transfer delivery risk to the supplier. Anything where month two should be informed by what users did with month one will be distorted by a fixed scope, because change requests become the real project and both parties start defending the original plan.
- Do I need my own tech lead to use a dedicated development team?
- Not necessarily, because a dedicated team comes with its own technical leadership as part of the arrangement. You do need someone who decides priorities, ideally weekly. A team with no product owner on the client side will build competently in a direction nobody chose. Staff augmentation is the model that genuinely requires your own senior engineer, since it assumes you supply the review and arbitration.
- How long should a dedicated team engagement run?
- Six months is a reasonable floor, because the value of the model comes from accumulated context and a shorter engagement pays the ramp cost without collecting the return. Below that horizon, staff augmentation or a fixed-scope piece is usually the better buy. Many companies start with a small bounded project as an audition, then move to a dedicated team once the supplier has proved capable.
- Can you switch between engagement models mid-project?
- Moving from a small fixed-scope piece to a dedicated team is common and works well, since the first engagement gives both sides a realistic estimate for the second. Moving the other way is harder and rarely priced in your favour. Whichever direction, use the transition to confirm that repositories, credentials and documentation are covered contractually, because model changes are when handover gaps surface.
