Most buyers choose a contract model by asking which is cheapest. That is the wrong question, and it is why so many engagements end in a change-order argument. The right question is simpler: who should carry the risk of the things nobody has thought of yet — and can they afford to?
What’s Covered
The Three Models, Plainly
| Model | What you agree | What you manage |
|---|---|---|
| Fixed price | A defined scope and one number, before work starts | Scope. Every change is a negotiation |
| Time & materials | An hourly or daily rate, with an estimate that is not a promise | Spend. You decide when to stop |
| Dedicated team | Named engineers for a monthly fee | Priorities. You run the backlog |
Notice what changes across the three rows: not the people, not the hourly cost of engineering, but what you are expected to control. Fixed price asks you to be certain in advance. Time and materials asks you to watch the meter. A dedicated team asks you to lead the work — which is why it fails fastest when nobody on your side has time to decide things.
Everything on our hire developers pages is sold as the third model, and we will explain below when that is the wrong choice.
Who Carries Which Risk
| Risk | Fixed price | Time & materials | Dedicated team |
|---|---|---|---|
| Estimate is wrong | Vendor | You | You |
| Requirements change | You (change orders) | Absorbed | Absorbed |
| Quality shortcuts | You inherit them | Shared | Shared |
| Idle capacity | Vendor | Nobody | You |
| Knowledge walking out | You | You | Mitigated by continuity |
Read the first two rows together, because they are the whole argument. Fixed price moves estimate risk to the vendor — and moves change risk to you. If your requirements are genuinely frozen, that is a good trade. If they are not, you have bought the one model that charges you for learning.
Where Fixed Price Breaks
Three failure modes, in the order we see them:
- The risk premium you cannot see. A vendor pricing a fixed bid has to cover being wrong. Industry estimates commonly put this padding at 10-40% over an equivalent hourly estimate — and those are vendor estimates, not survey data. If the project goes smoothly, you paid for a risk that never arrived.
- Change orders from a weak position. Once the contract is signed and your deadline is public, every change is priced by the only party who can deliver it. This is where relationships sour, and it has little to do with anyone being dishonest.
- Incentives point at “done”, not “good”. On a fixed bid, the fastest route to margin is the minimum that passes acceptance. You will not see the shortcuts until maintenance, which is exactly the pattern we described in what adding AI actually costs — the build is the cheap part and the living-with-it is not.
“Show me the assumptions this number depends on, and what happens to the price if each one is wrong.” A serious vendor has that list. One that produced the number by feel will change the subject.
Where Time & Materials Breaks
T&M is the honest model, and honest models have their own failure modes.
The first is drift. With no fixed end, a project can continue indefinitely while everyone feels productive. The fix is boring and effective: a not-to-exceed ceiling with a scheduled review, so spend forces a decision rather than sliding past one.
The second is asymmetry of attention. You are paying by the hour but reviewing by the week. Without a defined acceptance step, work that is 80% finished stays 80% finished for a month. Decide in advance what “done” means — the single biggest cause of failure in the Standish data is unclear requirements, at around 39%, with scope creep close behind at 33%.
The third is simply budget approval. Many organisations cannot approve an open number, whatever its merits. That is a real constraint, not a failure of imagination, and it is often the honest reason a fixed price is chosen.
Where Dedicated Teams Break
This is the model we sell, so here is the uncomfortable part first: a dedicated team is the most expensive way to buy software if you cannot keep it busy with decisions.
- Idle capacity is yours. You pay for the month whether the backlog was ready or not. Teams that wait on your approvals burn budget producing nothing.
- Ramp-up is real. The first weeks go into your domain, your codebase and your conventions. On a short engagement that cost never gets repaid, which is why we steer small one-off projects away from this model.
- No external deadline. Nothing in the contract forces delivery. Without your own milestones, a dedicated team can be comfortable and slow.
It earns its keep on continuing work: a product that changes every month, a backlog that never empties, and knowledge that compounds instead of leaving. That is why most of our Laravel, PHP and React engagements run for years rather than weeks — and why we price AI engineering the same way, since that work is never finished either.
What the Data Does and Does Not Say
We went looking for hard numbers comparing overruns by contract model. Here is the honest result.
| Claim | Status |
|---|---|
| Large IT builds run ~45% over budget | Traceable — McKinsey with Oxford, 5,400 projects |
| Unclear requirements ~39%, scope creep ~33% of failure causes | Standish CHAOS data, widely reported |
| ~30% of large tech programmes meet time, budget and scope | BCG survey, 2024 |
| “Fixed price overruns by X%, T&M by Y%” | We could not find a credible dataset. These numbers circulate between vendor blogs citing each other |
| “Dedicated teams are 15-25% cheaper over six months” | Unsupported. Plausible, unproven — and we would benefit from you believing it |
That last row matters. The strongest available evidence says projects fail on clarity, not on contract type. Choosing the model carefully is worth doing; expecting it to rescue a vague specification is not.
The Decision Table
| Your situation | Model | Why |
|---|---|---|
| Scope genuinely frozen, budget must be approved in advance | Fixed price | You are buying certainty and can afford the premium |
| Migration, integration or rebuild with a known endpoint | Fixed price or capped T&M | The unknowns are discoverable up front |
| Requirements still forming, or a first version | T&M with a ceiling | You will change your mind, and that should be cheap |
| Ongoing product work, backlog never empties | Dedicated team | Continuity and retained knowledge beat per-project pricing |
| You need capacity your local market cannot supply | Dedicated team | This is a hiring problem wearing a project costume |
| Nobody on your side can make decisions weekly | Fixed price | Do not rent a team you cannot direct |
That fifth row is most of our work. Companies in Germany, the Netherlands, Australia and the UAE rarely arrive with a project to quote — they arrive because a role has been open for four months. We covered the European version of that in why European companies hire Indian developers, and the capability-centre version in the tier-2 India GCC shift.
The Hybrid That Usually Wins
The pattern behind most of our longer engagements is not one model but two in sequence:
| Phase | Model | What it produces |
|---|---|---|
| 1. Discovery (1-3 weeks) | Small fixed price | Specification, architecture, risk list and a realistic estimate |
| 2. Build | Dedicated team or capped T&M | The actual software, with priorities you control |
| 3. Run | Dedicated team, smaller | Maintenance, iteration, the work nobody budgets for |
You buy certainty where it is cheap to produce — the thinking — and flexibility where pretending to be certain is expensive. A discovery phase also gives you something more useful than a quote: a document you can take to another vendor. If a vendor resists that, you have learned something early.
Run a paid one-week trial on a real ticket from your backlog. You will learn more about communication, code quality and honesty in that week than in any number of reference calls — and it costs less than the first change order of a bad fixed-price deal.
What Goes in the Contract
In all three models: full IP assignment on payment, an NDA, a data processing agreement where personal data is involved (GDPR Article 28 for European clients), a named exit clause covering handover of code, credentials and documentation, a notice period, and a written definition of done.
| Model | Add this clause |
|---|---|
| Fixed price | A change-order process with rates agreed before signing, and the assumption list the price depends on |
| Time & materials | A not-to-exceed ceiling with a review trigger, and weekly reporting of hours by task |
| Dedicated team | Replacement terms, notice period for scaling down, and named engineers rather than “resources” |
Our 30-point vetting checklist covers how to test a vendor’s claims before any of this is signed, and are you paying for developers or for AI covers the AI clause that belongs in all three models, and the India outsourcing guide covers the engagement mechanics end to end. If you are still choosing a country rather than a contract, India vs the Philippines is the more useful read first.
Frequently Asked Questions
What is the actual difference between the three?
Not price — risk. Fixed price puts estimate risk on the vendor and change risk on you. Time and materials puts both on you but charges nothing for changing your mind. A dedicated team puts capacity risk on you and keeps knowledge in the team. The model decides who pays when reality differs from the plan.
Is fixed price cheaper?
Rarely, once change orders are counted. The quote includes a risk premium — commonly estimated at 10-40% above an hourly equivalent, though these are vendor estimates rather than survey data. Fixed price is worth paying for when scope is frozen and the budget must be approved in advance; it is the worst choice when requirements are still moving.
When is a dedicated team wrong for me?
When the work is a single defined deliverable with no follow-on, when the engagement is shorter than about three months so ramp-up never pays back, or when nobody on your side can make decisions weekly. An idle dedicated team is the most expensive option in this article, and we will say so rather than sell you one.
What does the research actually show?
McKinsey and Oxford found large IT builds average about 45% over budget across 5,400 projects. Standish attributes failures mainly to unclear requirements (~39%) and scope creep (~33%), and BCG found only about 30% of large tech programmes met time, budget and scope. We could find no credible dataset comparing overruns between contract models — those percentages circulate between vendor blogs citing one another.
Can I mix models?
Yes, and it usually works better. A short fixed-price discovery produces a specification, architecture and honest estimate; the build then runs as a dedicated team or capped time and materials. You also end up owning a document you can take to any vendor, which is a useful side effect.
How do you work?
Dedicated team by default, with rates published per market on our hire developers pages — from $15/hour, month to month, with a 14-day replacement. We take fixed-price work when scope is genuinely frozen, and we turn it down when it is not, because a fixed bid on moving requirements ends badly for both sides.
The Short Version
If you read nothing else- You are choosing who carries risk, not what the work costs.
- Fixed price = vendor owns the estimate, you own every change.
- T&M = you own the spend; add a ceiling and a review trigger.
- Dedicated team = you own capacity; it fails when you cannot direct it.
- Fixed-price quotes carry a risk premium you never see itemised.
- Projects fail on unclear requirements (~39%), not on contract type.
- Per-model overrun statistics are vendor folklore — treat them as such.
- Best pattern: small fixed-price discovery, then dedicated team or capped T&M.
- Test with a paid one-week trial before any long contract.
Not sure which model fits your work?
Describe the work and we will tell you which of the three we would recommend — including when the answer is a fixed price from someone else, or no vendor at all.
Ask us