Fixed Price or Time and Materials: Who Carries the Risk?

A prospective client sends you one paragraph. They need a portal where their customers register, upload documents, follow their requests and pay online. They would like a fixed price by Thursday.

Every noun in that paragraph hides a decision. Which documents, and who checks them? How many kinds of request, and how many approval steps? Which payment provider, which languages, and which of the client's own systems does the portal talk to? Nobody can price those answers, because nobody has them yet. Someone will still put a number on it by Thursday.

A contract decides who holds the uncertainty

The uncertainty does not disappear when a price is written down. It moves to whoever signed for it. The clearest statement of this I know is in the US Federal Acquisition Regulation (FAR), the rulebook for federal purchasing, quoted here as it reads in 2025.

Fixed price puts the effort risk on the vendor. If the work takes twice as long, the vendor pays for the difference. The FAR says a firm-fixed-price contract "places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss" (FAR 16.202-1). A sensible vendor prices that risk in as contingency, and the client pays it whether or not the risk arrives. In return, the client gets rigidity. Anything not in the paragraph becomes a change request, and every change request becomes a negotiation.

Time and materials puts the effort risk on the client. The client pays for the hours worked, keeps the freedom to change direction, and keeps the savings if the work goes well. The FAR allows it only when the extent or duration of the work cannot be estimated accurately, and warns that it "provides no positive profit incentive to the contractor for cost control or labor efficiency" (FAR 16.601).

What each one rewards

Incentives follow the risk. Under fixed price, the vendor's margin grows when the work shrinks. The FAR calls this the maximum incentive "to control costs and perform effectively", and it is. It is also why every vague sentence gets the narrowest reading and every gap becomes a change request. That is not villainy. It is the contract working as written. Under time and materials, the vendor is paid by the hour, so nothing in the contract rewards fewer hours. The FAR's answer is that the buyer has to watch the work, and watching has a cost too.

Source: my own summary. The effort-risk row follows FAR 16.202-1 and 16.601, and the time-and-materials incentive follows FAR 16.601.

Neither type is the honest one. Each is a choice about who carries the risk and what the other side has to watch. The FAR's own advice: "Negotiating the contract type and negotiating prices are closely related and should be considered together" (FAR 16.103). A fixed price on a one-paragraph scope is insurance, and the contingency is the premium. Sometimes the premium is worth paying. It should be a choice, not a surprise.

Workable middles

The useful contracts sit between the two, and most of them work by shrinking the uncertainty before anyone prices it.

• A fixed-price discovery phase. A short phase, priced and paid for, whose deliverable is the definition: users, flows, integrations, acceptance criteria and a ranged estimate for the build. It narrows the range by forcing decisions, and it keeps estimates, targets and commitments apart until there is something to commit to.
• Time and materials with a cap. The client keeps the flexibility, and the vendor carries the risk above an agreed ceiling. The FAR requires this for its own time-and-materials contracts: "a ceiling price that the contractor exceeds at its own risk" (FAR 16.601).
• Fixed price for small, well-defined phases. Price each phase once the one before it has made its scope clear. The FAR points the same way: avoid long use of time and materials once experience gives a basis for firmer pricing (FAR 16.103).
• An agreed change process. Decide before signing how a change is requested, estimated, approved and paid for, at what rate, and who can say yes. Then a change is a decision rather than a dispute, and the large ripple of a small request gets stated before anyone agrees to it.

None of these replaces working together. One of the four values in the Agile Manifesto (2001) reads "Customer collaboration over contract negotiation", and the manifesto adds that there is value in the items on the right. Negotiating the contract is one of them. Collaboration is easier when the contract has already said who pays for a surprise.

When fixed price works, and when it fails

I write this from the vendor's side: government-scale systems from pre-sale to handoff, and a government project where my company was the prime vendor and I owned 75% or more of the technical work. The general lesson from that side of the table is that a price is only as firm as the definition under it.

Fixed price works when the scope is small, written down and testable, when the vendor has built the same kind of thing before, and when the client can say no to changes or pay for them. The FAR's test is similar: use a firm fixed price when "the risk involved is minimal or can be predicted with an acceptable degree of certainty" (FAR 16.103).

It fails when the scope is a paragraph, when acceptance depends on taste ("modern", "user-friendly"), when the work depends on the client's own systems and people, and when scope, date and price are all fixed at once. Something has to give in that last case, and it is usually quality, because quality is the one thing nobody wrote down. It also fails quietly when a vendor bids low and plans to recover the difference through change requests. The client then pays the premium after all, one request at a time.

Waiting has a price as well. A month spent negotiating a fixed price for a system described in one paragraph is a month in which nothing gets built, and each week of waiting has a cost that belongs in the comparison.

A fixed price does not remove the uncertainty. It decides who is holding it when it arrives, and how much they charged for holding it.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.