The short answer
Neither contract type inherently protects you. That's the uncomfortable truth most vendor sales pages skip over. A fixed-price contract doesn't protect you from bad estimates — it just moves the risk of a bad estimate onto the vendor, and vendors who feel that risk respond in predictable ways: they pad the number before they sign, and they fight you on every change request afterward, because change orders are where they recover the margin they gave up on the base price. Time-and-materials doesn't protect you either. It removes the vendor's incentive to lowball, but it hands you an open-ended bill unless someone is actively watching the clock and the scope on your behalf.
The real protection is structural: pick the contract type that matches how well-defined the work actually is, build in the right checkpoints, and be honest with yourself about which risk you're more able to absorb — a vendor padding a number, or a project drifting past its budget. This article walks through both models, what happens when reality diverges from the plan (it always does, to some degree), and what a hybrid structure looks like in practice.
What each model actually is
A fixed-price contract sets a total cost and, usually, a deliverable list and timeline, before work starts. You pay that number regardless of how many hours it actually takes the vendor to get there. A time-and-materials (T&M) contract bills for actual hours worked at an agreed rate, plus materials or tools, with no hard ceiling unless one is negotiated separately. Everything else — how change requests are handled, who eats the cost of a bad initial estimate, how disputes tend to play out — flows from that one structural difference.
| Dimension | Fixed-Price | Time-and-Materials |
|---|---|---|
| Best for | Well-specified, stable scope — a defined feature set, a known integration, a spec that isn't going to move | Discovery-heavy or evolving work — new products, unclear requirements, anything still being figured out as you build |
| How change requests are handled | Formal change orders, usually with their own negotiation and markup — every change is a separate mini-contract | Just more hours against the existing rate — no separate negotiation, but no ceiling either |
| Cost predictability | High up front, low once change orders start stacking up | Low up front, high once you have a few sprints of actual velocity data and a burn-down you trust |
| Incentive alignment | Vendor is incentivized to minimize hours and resist scope changes — sometimes at the expense of quality | Vendor has less incentive to work efficiently unless there's trust, reporting, and a relationship worth protecting |
| Typical dispute pattern | "That's not in scope" arguments over ambiguous spec language | "Why did this take so long" arguments over hours and utilization |
Why this is a risk-management decision, not paperwork
It's tempting to treat the contract type as a formality that legal or procurement sorts out after the real decisions are made. The numbers say otherwise. Industry research on software project delivery consistently puts average budget overruns at around 45%, with roughly 28% of projects exceeding a 100% overrun — meaning more than a quarter of software projects end up costing double what was planned or worse. Only about 30% of software projects are considered fully successful by the usual measures of scope, budget, and schedule. Roughly half land in the "challenged" category — some combination of over budget, over schedule, or delivered with reduced scope. Around one in five fail outright. Separately, longer-running data on software project cost has found that a large majority of projects, on the order of 80%, have historically ended up costing roughly double their original planned budget.
Read those numbers again with the contract question in mind. If close to half of all software projects run over budget or over schedule, the question isn't whether your project will diverge from the original plan — it's who absorbs that divergence when it happens, and how cleanly. That's what a contract actually decides. It's not paperwork. It's the pre-agreed answer to "what happens when this doesn't go exactly as planned," and on a majority of projects, it doesn't.
If a vendor is eager to sign a fixed-price contract off a vague one-page spec, be cautious. A serious vendor pushes back and asks for more discovery before committing to a number, because they know an underspecified fixed-price deal is a trap for both sides. A vendor who signs anyway is often not planning to make their margin by doing the work efficiently — they're planning to make it on change orders, betting that the spec's ambiguity will work in their favor once you're already committed to them. The eagerness itself is the signal, not the price.
Where experienced teams actually land: hybrid and milestone-based structures
In practice, the fixed-price-versus-T&M question is rarely all-or-nothing for teams that have been through a few of these engagements. What a lot of experienced buyers and vendors converge on is a hybrid: fixed price for the parts of the project that are genuinely well understood, and T&M for the parts that aren't yet.
Concretely, that usually looks like milestone-based fixed pricing. Discovery and design run as a short, cheap, T&M or fixed-fee phase specifically because nobody — including the vendor — fully understands the problem yet at that stage. Once discovery produces a real spec, later phases with clear, testable deliverables get priced as fixed milestones. Anything still genuinely exploratory — a new integration with an undocumented third-party system, an ML component whose accuracy target isn't known until you've tried it, a UX flow that needs user testing to settle — stays on T&M with a not-to-exceed cap, so the client isn't exposed to a truly open-ended bill.
The logic is simple: fixed price only works when both sides can actually estimate the work with confidence. Forcing a fixed number onto genuinely unknown work just moves the guesswork into the vendor's padding, where the client can't see it. Forcing T&M onto well-understood, repeatable work removes an incentive for efficiency that a fixed milestone naturally provides. Matching the pricing model to the actual certainty of the scope, phase by phase, is what lets both sides negotiate in good faith instead of gaming the structure. This is roughly how we structure engagements at Hardened Soft — start with a scoped discovery phase, then move to milestone pricing once there's something concrete enough to price honestly.
What to ask a vendor before you sign
A few direct questions tend to surface more than a proposal document will.
- How did you arrive at this number? A vendor who can walk you through their estimate — task breakdown, assumptions, buffer — has done real work. A vendor who just gives you a total has probably padded it or guessed.
- What happens to a change request, specifically? Get the actual process: is there a change-order markup, a fixed turnaround for re-quoting, a threshold below which changes are absorbed for free? Vague answers here predict friction later.
- Can I see time or progress reporting on a T&M engagement? If the answer is no, or it's just a monthly invoice with no detail, that's the open-ended-billing risk showing up before you've even signed.
- What's not-to-exceed on this, and how firm is it? A T&M contract with a real cap, even a generous one, is a meaningfully different commitment than one with no ceiling at all.
- What would make you walk away from fixed price on this spec? A vendor who's thought about this has a real answer. One who hasn't is telling you they'll sign anything.
None of these questions are adversarial. A vendor worth working with will have straightforward answers, because they've had this conversation before — it's part of how outsourced engagements should be structured from day one, not something negotiated after a dispute has already started.
Not sure which model fits your project?
Tell us roughly what you're building and how settled the spec is, and we'll give you a straight answer on whether fixed-price, T&M, or a milestone hybrid makes sense — before you sign anything.
Frequently asked questions
Can a contract be fixed-price and still have change requests?
Yes, and it usually will. Almost no real project stays perfectly within its original spec. A well-written fixed-price contract doesn't pretend change won't happen — it defines up front how a change request is priced, quoted, and approved, so a scope change is a quick negotiation instead of a dispute.
Is Time-and-Materials just an excuse for open-ended billing?
It can be, if there's no reporting and no cap. It doesn't have to be. T&M with regular time reporting, sprint-level visibility, and an agreed not-to-exceed ceiling gives you most of the flexibility with a lot less of the risk. The billing model isn't the problem — the absence of transparency and a cap is.
What happens if scope is still unclear after discovery?
That's a signal to keep more of the engagement on T&M, not to force a fixed number onto uncertainty. A vendor pushing you toward fixed-price on a still-fuzzy scope is asking you to pay for their padding instead of paying for actual discovery work. It's reasonable to run a second, shorter discovery pass before locking in fixed milestones.
Does Hardened Soft only do one of these?
No. We use fixed pricing for well-scoped milestones and T&M, usually with a cap, for discovery or genuinely exploratory work. Which one applies depends on how well-defined your project is when we start, and that mix can shift as the project moves from discovery into build.