# Fixed Price vs Time and Materials: Which Contract Fits?

> Choose a fixed price when scope is stable and precisely specified: the vendor carries the cost risk but charges a premium for it. Choose time and materials when requirements will evolve: you pay actual effort and control scope yourself. A common middle ground is time and materials with a not-to-exceed ceiling and committed must-have scope.

- URL: https://go-projects.de/en/estimates-and-budget/fixed-price-vs-time-and-materials/
- Language: en
- Updated: 2026-10-19
- Publisher: Go Projects (OnlineBuilders LLC, https://onlinebuilders.biz)

Fixed prices feel safe. The number is in the contract and it won't go up. That's the hope, anyway. Yet fixed-price software projects get expensive precisely when everyone realises halfway through that something is needed differently than written. Then the change negotiations start, and every change costs extra.

Time and materials, by contrast, looks like a blank cheque. That's only half true as well. With the right guardrails it is often the more honest model.

## What each model actually promises

The difference isn't just how invoices are calculated. It's about what the vendor owes you. Under a fixed-price contract the vendor typically commits to a result: working software meeting defined requirements, followed by an acceptance process. Under time and materials the vendor commits to effort, meaning qualified people's time, and usually not to a specific outcome.

The US federal procurement rules are a telling reference here. [FAR 16.601](https://www.acquisition.gov/far/16.601) allows government agencies to use time-and-materials contracts only when the extent or duration of work cannot be estimated accurately up front, and requires a ceiling price that the contractor exceeds at its own risk. The same logic works for private projects.

**Fixed price and time and materials compared**

| | Fixed price | Time and materials |
|---|---|---|
| Vendor commits to | result | effort |
| Cost risk carried by | vendor | client |
| Risk premium in price | yes | no |
| Mid-project changes | via change requests only | any time, costs time |
| Formal acceptance | yes | only if agreed |
| Upfront specification effort | high | low to medium |
| Works best with | stable, clear scope | unclear or evolving scope |

## Why fixed price usually costs more

Sensible vendors don't price a fixed bid at the most likely estimate. They price well above it, because they carry the risk. Here's the mechanism in numbers.

**How an estimate becomes a fixed-price bid (example)**

- Expected effort: 47.3 days = $37,840
- 90% value used as pricing basis: 53.0 days = $42,400
- Premium for specification gaps (assumed 10%): $4,240
- **Fixed-price bid: $46,640**

Estimate from the PERT example in our estimation guide; day rate $800. The risk premium is an assumption for illustration.

If the project goes normally, you pay roughly $8,800 more on fixed price than on time and materials. If it goes badly, you save. That premium is an insurance payment, and insurance only makes sense when the risk is real and you can't absorb it.

There's a quieter effect too. On a fixed price, the vendor has every reason to read scope narrowly. Each ambiguity in your [requirements document](https://go-projects.de/en/planning/software-requirements-document-template/) becomes a potential change request. That's not bad faith. It's how the model works.

## When time and materials is the better choice

Time and materials fits when you're still learning what the product must do: new products, projects with lots of user testing, anything where the market writes half the requirements. Agile delivery is built for this, as covered in [agile vs waterfall](https://go-projects.de/en/running-the-project/agile-vs-waterfall/).

Without guardrails, though, it really can become a blank cheque. Put these four into every T&M contract:

1. A not-to-exceed ceiling with a written warning at 80 percent.
2. Time tracking per task, visible to you weekly.
3. Short cycles of two to four weeks, each ending in working software.
4. A right to terminate at the end of any cycle without penalty.

With those in place you can walk away whenever progress disappoints. Fixed price doesn't give you that kind of safety.

One caution for long engagements with individual contractors: if they work inside your team, take instructions like employees and bill by the hour for months, some jurisdictions may treat them as employees. The UK's IR35 rules are one example. Check before you sign.

## Hybrid models that work

Between the extremes sit models that combine the strengths.

### Fixed price per phase

Start with a small paid engagement for discovery and a prototype, then a quote for the build based on what you learned. The first step cuts uncertainty before the big cheque is written.

### Fixed budget, flexible scope

Budget and timeline are locked. Must-haves are committed; shoulds and coulds get built while budget lasts. This only works with disciplined [MoSCoW prioritization](https://go-projects.de/en/planning/moscow-prioritization/).

### Capped T&M with incentives

Hourly billing with a ceiling, plus a bonus or holdback tied to agreed milestones. It shares risk fairly but takes longer to negotiate.

## What every software contract needs, whatever the model

Some clauses get forgotten in the pricing debate, and they cause more grief later than the price itself:

- Intellectual property: who owns the code, or what licence do you get? Require source code handover.
- A change procedure: who may request changes, how they're assessed, who approves. Our [change request process](https://go-projects.de/en/running-the-project/change-request-process/) guide has a template.
- Acceptance criteria and a test procedure, even on T&M if you expect a working system at the end.
- Documentation and handover: credentials, deployment instructions, an architecture sketch. Without them you're locked in, like it or not.

The last item decides whether you can ever switch vendors. It costs little to include and a lot to lack.

For larger contracts, have a lawyer who knows technology agreements read the draft once. It's cheap compared with a dispute.

## A three-question test

Answer yes or no:

- Could you write a requirements document today that will barely change in six months?
- Is this closer to rebuilding a known process than inventing a new product?
- Do you lack anyone internally with weekly time for product decisions?

Three yeses point to fixed price. Mostly no points to time and materials with guardrails, or a hybrid. Budget figures for either model are discussed in [custom software development cost](https://go-projects.de/en/estimates-and-budget/custom-software-development-cost/).

If you want a reference point for how partner builds can be structured, see [how OnlineBuilders works](https://onlinebuilders.biz/how-we-work) and compare it with the terms you're being offered.

Next step: take the last quote you received and ask the vendor which estimate and which risk premium sit inside the price. The answer tells you whether fixed price is really the cheaper option there.

## FAQ

### Is fixed price always more expensive?

If the project runs normally, usually yes, because the vendor prices in a risk premium. If it runs badly and the scope was genuinely fixed, the client saves. It works like insurance: worth it only when the risk is real and you can't absorb it yourself.

### What is a not-to-exceed clause?

A cap on the total billable amount in a time-and-materials contract. The vendor must stop or seek written approval before exceeding it. You can add a duty to warn you earlier, for example at 80 percent of the cap.

### What is an agile fixed price?

A hybrid where budget and timeline are fixed but scope can be swapped under clear rules. A new requirement only comes in if one of similar size goes out.

### Who owns the code under each model?

That depends on the contract, not the pricing model. Make sure the agreement assigns intellectual property or grants the licence you need, and requires source code and documentation handover.

Photo: Tasma3197, CC BY-SA 3.0 (https://commons.wikimedia.org/w/index.php?curid=15368339)