Pick fixed price when the scope is genuinely fixed, a dedicated team when the destination is clear but the route is not, and staff augmentation when you already have a functioning engineering organisation and a specific skills gap. Choosing wrong is the most expensive procurement error in software, and it happens because buyers choose on price when the real variable is who carries the risk of change.
This compares the three models on the dimensions that actually decide outcomes: who owns the spec, who absorbs change, who manages delivery, and what happens when the estimate is wrong. It also covers the failure mode of each, which is the part sales decks omit.
The three models in one table
| Fixed price | Dedicated team | Staff augmentation | |
|---|---|---|---|
| You buy | A defined outcome | A team's capacity and delivery | Individual engineers |
| Who writes the spec | You, in full, up front | Shared, iteratively | You, continuously |
| Who manages delivery | Vendor | Vendor | You |
| Who absorbs scope change | You, via change orders | Shared, by reprioritising | You |
| Cost predictability | High, until change orders | Medium, fixed monthly | High per head, variable output |
| Effective rate | Highest (risk premium built in) | Middle | Lowest |
| Speed to start | Slow, 3 to 8 wks of scoping | Medium, 2 to 4 wks | Fast, 1 to 3 wks |
| Requires in-house eng leadership | No | Helpful | Mandatory |
| Best for | Well-defined, bounded builds | Products that will evolve | Filling a known skills gap |
Fixed price
You define the deliverable, the vendor quotes a number, and the vendor carries the risk of underestimating.
When it is right
Genuinely bounded work with an unambiguous definition of done: a marketing site, a migration with known endpoints, an integration between two documented systems, a well-specified mobile app v1 where the flows are already designed.
The failure mode
Fixed price prices risk, not effort. A competent vendor adds 25% to 40% contingency because they are absorbing your uncertainty. If the scope was actually clear, you paid a premium for nothing. If it was not, you spend the project in change-order negotiations, and every conversation becomes adversarial: the vendor is incentivised to deliver the literal brief at minimum cost, and you are incentivised to argue that everything was implied.
This is where a large share of outsourcing failures come from. The team implements the brief correctly and still builds the wrong thing, because "correct" was defined by a document written before anyone learned anything. The contract mechanics that decide who pays in that situation are covered in our software development contract checklist.
What to insist on
A written change-order process with a rate and a turnaround time, agreed before signing. Acceptance criteria per deliverable, not one at the end. And a discovery phase billed separately, so the fixed price is set after the unknowns are resolved rather than before.
Dedicated team
You retain a team, usually 3 to 8 people including a lead, QA, and design, for a monthly fee. They work only on your product, manage their own delivery, and you set priorities.
When it is right
The default for most product builds, and the model we recommend most often. It fits when you know the destination but not the exact route, when the product will keep evolving after v1, and when you do not have the engineering management bandwidth to direct individuals daily.
The failure mode
Drift. Without a clear roadmap and a visible definition of done, a dedicated team will happily bill for months of motion without shipping anything that changes the business. The model removes the adversarial dynamic of fixed price and replaces it with the risk of comfortable indefiniteness.
What to insist on
Quarterly outcome targets, not just sprint velocity. A named team roster with turnover bounded in the contract, because the value here is people who accumulate context. A demo every two weeks that a non-technical stakeholder can evaluate. And a 30-day exit clause, which costs you nothing if things go well and saves months if they do not.
Staff augmentation
You hire individual engineers who join your team, attend your standups, and work in your process. You manage them.
When it is right
You have a working engineering organisation, a tech lead who can direct people, and a specific gap: you need two React Native developers for six months, or an ML engineer for a project your team cannot staff. The 2026 talent shortage is in specialised skills rather than headcount, which is precisely what this model addresses. It also gets you moving in one to three weeks against nine to eighteen months to recruit, ramp, and retain the equivalent internally.
The failure mode
Buying staff augmentation when you have no engineering management. This is the single most common expensive mistake we see. Non-technical founders buy augmented engineers because the hourly rate is lowest, then have nobody to define architecture, review code, or decide trade-offs. Six months later there is a codebase nobody owns, and it costs more to fix than a dedicated team would have cost to build properly. If you cannot name the person who will do code review, this model is not available to you at any price.
What to insist on
Interview every individual, exactly as you would a hire. Insist on the same person for the full term, with replacement notice in the contract. Agree a ramp period, usually two to four weeks, where you expect reduced output rather than full velocity.
The decision tree
- Do you have an engineer who will own architecture and review code? If no, staff augmentation is off the table. Go to 2.
- Can you write acceptance criteria today that will still be right in four months? If yes, fixed price is viable. If no, dedicated team.
- Will the product keep changing after launch? If yes, dedicated team, because fixed price restarts the procurement cycle on every change.
- Is the work bounded and one-off? Fixed price, with discovery billed separately.
- Do you have a team and a named skills gap? Staff augmentation.
Cost compared honestly
Same work, 6 months, roughly 4 people. Rates assume a competent offshore team; see offshore rates by country for regional bands.
| Model | Nominal cost | Your time | Realistic total |
|---|---|---|---|
| Fixed price | $150,000 | 2 hrs/wk | $150k + change orders, typically $175k–$200k |
| Dedicated team | $132,000 | 4 hrs/wk | ~$140,000 |
| Staff augmentation | $108,000 | 12+ hrs/wk | $108k + your management cost, and unusable without a lead |
Staff augmentation looks 28% cheaper and is, if and only if you already employ the management layer. Price your own hours into the comparison honestly. A founder spending twelve hours a week directing engineers is not spending them on sales.
Hybrid arrangements that work
- Fixed-price discovery, then dedicated team. Our default recommendation. A 2 to 4 week paid discovery producing architecture, scope, and estimates, after which you commit to a team with real information. Low commitment, and the discovery artefact is yours to take to another vendor if you want to.
- Dedicated team, then augmentation. The vendor builds v1, then one or two of their engineers stay on as your internal team ramps up. Preserves context through the handover, which is where most transitions lose three months.
- Fixed price with a change budget. Fixed scope plus a pre-agreed pool of hours for changes at a set rate. Removes the adversarial renegotiation without removing cost predictability.
Frequently asked questions
What is the difference between staff augmentation and a dedicated team?
Who manages delivery. With staff augmentation you hire individual engineers who work inside your process under your technical leadership, and you own architecture, code review, and prioritisation. With a dedicated team, the vendor supplies a self-managing unit including a lead and QA, and takes responsibility for delivery. Staff augmentation is cheaper per head and only works if you already have engineering management.
Is fixed price safer than time and materials?
It transfers estimation risk to the vendor, but it does not remove risk. Vendors add 25% to 40% contingency to absorb that risk, and any change becomes a change order priced without competitive pressure. Fixed price is safer only when the scope genuinely will not change, which is rarer than buyers assume.
Which model is cheapest?
Staff augmentation has the lowest hourly rate, dedicated team is in the middle, and fixed price is highest per unit of work because it prices risk. Landed cost often reverses that order once you include your own management hours and change orders. Compare total cost to a shipped outcome, not rate.
Can a non-technical founder use staff augmentation?
Not safely. Without someone who owns architecture and reviews code, augmented engineers produce work nobody is accountable for, and the remediation cost usually exceeds what a dedicated team would have cost in the first place. Non-technical founders should use a dedicated team or fixed price with a vendor-supplied technical lead.
How long should a dedicated team contract run?
Three to six month initial terms with a 30-day exit clause. Shorter than three months and the team never gets past ramp-up. Longer initial commitments without an exit clause remove your only real leverage if delivery disappoints.
What is the best model for an MVP?
Fixed-price discovery followed by a dedicated team, in almost every case. MVP scope always changes once real users touch it, which makes a pure fixed-price contract adversarial by month two. Discovery gives you the estimate reliability of fixed price without locking the build scope prematurely.
Key takeaways
- The model is a decision about who carries the risk of change, not about price.
- Fixed price only fits genuinely bounded work, and it carries a 25% to 40% risk premium.
- Dedicated team is the right default for products that will keep evolving.
- Staff augmentation requires in-house engineering management. Without it, it is the most expensive option.
- Paid discovery followed by a dedicated team beats a premature fixed-price contract in most builds.
Working out which one you need
The decision tree above resolves most cases in five minutes, and the ones it does not resolve usually hinge on a detail about your team rather than your project. Tell us what you are building and who you already have and we will tell you which model we would recommend, including when that recommendation is the one we would earn least from. We have turned down fixed-price work because the scope was not stable enough to price honestly, and we would rather say that up front than argue about it in month three. Related: offshore rates by country, the contract checklist, and our services and engagement options.