Contract structure determines behaviour more reliably than any statement of values in a vendor's proposal. Each of the three dominant models creates a specific set of incentives, and those incentives will assert themselves under pressure regardless of goodwill on either side. Choosing well means picking the model whose failure mode you can most easily tolerate - because you will meet it.
01The three models, and what each optimises for
These are not interchangeable pricing wrappers around the same service. They allocate risk, control and knowledge differently, and each suits a genuinely different situation.
| Model | Risk sits with | You must supply | Fails when |
|---|---|---|---|
| Fixed price | Vendor | A complete, frozen specification | Scope moves at all |
| Staff augmentation | You | Management and technical direction | You lack capacity to direct |
| Dedicated team | Shared | Product ownership and priorities | Priorities are unclear |
02Fixed price: narrow but genuinely useful
Fixed price works when the deliverable is genuinely fixed and specifiable in advance - a migration with known endpoints, an integration against a documented API, a defined compliance implementation. In those cases it transfers real risk and the premium buys something worth having.
It fails on product development, because product development is discovery. The moment you learn something that changes the requirement, you are in a change-request negotiation, and the vendor's incentive is to interpret the original scope narrowly. Teams end up shipping the specification rather than the right product, which is the expensive kind of on-time delivery.
- Good for: migrations, integrations, defined compliance work, well-bounded rebuilds.
- Bad for: new products, anything with user research still open, evolving requirements.
- Watch for: change-request pricing that is far above the base rate.
03Staff augmentation: cheap rate, hidden cost
Staff augmentation supplies engineers into your team under your direction. The rate is usually the lowest of the three because the vendor carries almost no delivery risk - they supply capable people, and outcomes are your problem.
That is fine if you have strong technical leadership and a well-run backlog. It fails when a company adopts it precisely because it lacks engineering management capacity, which is a common and expensive mistake. Augmented engineers without direction produce activity rather than progress, and the model gives the vendor no contractual reason to raise the alarm.
04Dedicated team: the default for ongoing product work
A dedicated team gives you continuity of knowledge, the ability to reprioritise each sprint, and a vendor who carries delivery accountability while you retain product ownership. For sustained product engineering it is usually the right structure, and it is what most mature vendor relationships converge on.
The trade-off is that it demands real product ownership from you. The model rewards a clear backlog and punishes its absence - a dedicated team with vague priorities will stay busy and deliver little, and because velocity looks healthy the problem can run for months before anyone names it.
- Insist on the same named engineers over time; rotation destroys the model's main advantage.
- Expect a 4-8 week ramp before full productivity on a non-trivial codebase.
- Review outcomes, not activity - story points are not a deliverable.
- Budget 15-20% of engineering cost as your own management overhead.
05Practical selection
Most organisations should default to a dedicated team for core ongoing work, use fixed price selectively for genuinely bounded projects, and treat staff augmentation as a targeted fix for a specific capacity or skills gap rather than a delivery strategy.
Whichever you choose, the terms that matter most are the same: IP assignment on payment, named individuals rather than anonymous capacity, client-owned repositories and cloud accounts, and a defined transition obligation at exit. Those four remove most of the leverage a vendor could otherwise hold, and none of them are controversial for a partner acting in good faith.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.