Fixed price vs time and materials: the clause that fixes both

The US federal rulebook, the buyer most attached to fixed price, will only let a contracting officer sign a time-and-materials deal if it carries "a ceiling price that the contractor exceeds at its own risk". That clause settles most of the fixed price vs time and materials argument for custom software. By the end of this piece you will know which contract type fits your statement of work, what a capped time and materials contract has to say to protect you, and when fixed price is still the right call.

The short answer: fixed price works when you can write a reasonably definite specification before work starts. Custom platforms rarely have one. For those, capped time and materials, with a fixed-price discovery phase in front of it, gives you the budget certainty you wanted from fixed price without paying for the vendor's risk buffer or fighting over every change request.

Contract type	Who carries an overrun	What it asks of you	Where it fits
Fixed price	The vendor, priced into the quote	A specification complete enough to price at the outset	Well-defined, repeatable work; discovery phases
Time and materials	You, at the agreed day rates	Active oversight of how the hours are spent	Work whose extent cannot be estimated up front
Capped time and materials	You up to the cap, the vendor beyond it	Oversight, plus a written rule for raising the cap	Custom software built iteratively against a budget

The rows paraphrase two public-sector sources: the US Federal Acquisition Regulation (FAR), as amended by FAC 2026-01 effective 13 March 2026, and the UK Government Digital Service's guidance on paying for Digital Outcomes and Specialists services, published in 2016 and withdrawn on 31 December 2025. Neither binds a private company. We use them because procurement rulebooks have to write down a mechanism, where vendor blogs only list pros and cons.

Fixed price vs time and materials comes down to whether you can estimate the work

Both rulebooks draw the line in the same place. FAR 16.202-2 says a firm-fixed-price contract suits services bought "on the basis of reasonably definite functional or detailed specifications" when fair prices can be set at the outset. FAR 16.601(c) says time and materials may be used "only when it is not possible at the time of placing the contract to estimate accurately the extent or duration of the work or to anticipate costs with any reasonable degree of confidence."

So the useful question is not which contract type is safer. It is whether the document you are about to attach to the statement of work is a specification or a wish list. A list of screens, integrations and user roles that nobody has tested against real users is the second kind, however long it is.

The UK guidance put the same test in plainer language: a fixed price approach "works best when your requirements are well defined so the supplier can provide an accurate quote without incorporating extra costs." The last clause is the one buyers skip. A vendor that quotes a fixed price on an undefined scope has to add a contingency for what it cannot see, and you pay that contingency whether the risk materializes or not.

The strongest case for a fixed price contract in software development

Fixed price deserves a fair hearing, because the FAR's own description of it is close to a sales pitch. FAR 16.202-1 says a firm-fixed-price contract "places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss", provides "maximum incentive for the contractor to control costs and perform effectively" and "imposes a minimum administrative burden upon the contracting parties."

That last point matters to a 100-person company. You may not have a full-time product owner to watch a vendor's hours. A fixed price lets the board approve one number, lets finance stop asking for monthly reforecasts, and puts the overrun on someone else's balance sheet. Even 18F, the GSA digital team whose guidance recommends time and materials for custom agile software, concedes in its De-risking Government Technology field guide that "legislators and overseers encourage" fixed price.

The answer to that case is in FAR 16.202-2(d), which 18F quotes back at its readers. Fixed price assumes "performance uncertainties can be identified and reasonable estimates of their cost impact can be made, and the contractor is willing to accept a firm fixed price representing assumption of the risks involved." On a custom platform, the uncertainties you cannot identify are the ones that cost money. The vendor either prices them in or argues them out later as change requests.

Change requests in a fixed price software contract

Change requests are where fixed price quietly turns back into time and materials, only with worse paperwork. Every new requirement has to be scoped, priced and approved before work continues, and each one is a negotiation where the vendor holds the information. 18F reports that programs which tried to fix the price of agile work per sprint or per story point produced "unnecessary gamesmanship and fighting", because "there are no canonical, objective ways to measure the number of user stories included in a given sprint or the size of a story point."

18F's guide also makes a point most buyers miss: with fixed price, you lose the cheap exit. If the vendor underperforms, you cannot simply stop assigning work. Under time and materials, the guide says, "no more work needs be assigned to the contractor, which effectively terminates the contract."

What is a capped time and materials contract?

A capped time and materials contract bills actual hours at fixed rates, up to a ceiling the vendor cannot charge beyond. The UK guidance defined it as "the same as a time and materials approach but there's a limit on how much you have to pay for the work. If you reach the limit before the work is finished, the supplier has to complete the work at their own cost." It added that if the supplier finishes early, "you only pay them for the time they took."

That is the property fixed price cannot offer. 18F puts it bluntly: time and materials "provides the opportunity for costs to come in under budget, which never happens with FFP." A not-to-exceed contract in software gives you the same worst case as a fixed price, a known maximum, while keeping the upside if the work goes faster than planned.

Notice the gap between the two rulebooks, though. FAR 16.601(d)(2) says only that the contractor exceeds the ceiling "at its own risk." The UK wording spelled out the consequence: the supplier completes the work at its own cost. A mid-market buyer should not rely on a phrase; write the consequence into the contract, including what "the work" means at the moment the cap is hit.

Secondary sources drift here too. 18F's newer buying guide states that a time-and-materials contract "can't exceed three calendar years in duration". The current FAR 16.601(d)(1) text reads differently: three years is the point at which the contracting officer's determination and findings need approval from the head of the contracting activity, not an outright limit. If a vendor cites a rule to justify a contract term, read the rule.

How to control costs on a time and materials contract

The FAR is candid about the weakness of time and materials. Section 16.601(c)(1) says a time-and-materials contract "provides no positive profit incentive to the contractor for cost control or labor efficiency. Therefore, appropriate Government surveillance of contractor performance is required." A cap limits the damage; surveillance is what keeps you from hitting the cap with half a product. These are the clauses we would want to see in any statement of work for a time and materials contract:

1. A ceiling the vendor exceeds at its own risk, with the consequence written out: whether the vendor finishes the agreed scope at its own cost, and how that scope is defined at that point.
2. A rule for raising the ceiling. FAR 16.601(e) requires the contracting officer to analyze pricing and other relevant factors and document the decision before any increase. Your version can be lighter, but it should exist before the first request arrives.
3. Fixed rates per role. FAR 16.601(c)(2)(i) requires separate fixed hourly rates for each labor category. A blended rate hides who is actually doing the work.
4. Invoices with exact billing data. 18F's buying guide argues that time-and-materials invoices protect the buyer better than fixed-price ones precisely because each must show actual time incurred.
5. Short units of work. The UK guidance required each statement of work to "take no longer than a month", so overruns surface while they are small.
6. A named product owner on your side. 18F's case for time and materials rests on an engaged product owner who knows what the team is doing every day and inspects performance every sprint.

The last item is the honest cost of capped time and materials. If nobody in your company can spend real time each week prioritizing the backlog and reviewing what shipped, the cap becomes your only control, and you will reach it. Our software development company checklist covers the vendor-side signals worth verifying before you hand over that budget.

When should you use a fixed price contract?

Fixed price is the right choice when the FAR's own conditions hold: the scope is definite enough that two competent vendors would price it within a sensible range, and the uncertainties are known well enough to cost. In custom software that usually means three situations.

• A fixed price discovery phase. A short, bounded engagement whose output is the specification, architecture and estimate that the build will run against. The deliverables are definable even when the product is not.
• Well-understood, repeatable work, such as a migration between known systems or a rebuild of a feature set that already exists and is documented.
• Small, tightly specified increments where you would rather pay a risk premium than staff oversight.

Fixed price is the wrong choice if you expect user research to change the product, if integrations depend on third-party systems nobody has tested against, or if you plan to add or remove team members as the work evolves. 18F's guide notes that under fixed price, agencies "don't have the flexibility to change the contractor software development team size over time based on product needs."

Which contract type for custom software, then?

For most custom platforms, the answer is both, in sequence: fixed price for discovery, then capped time and materials for the build, with the cap set from the discovery estimate. The discovery output becomes the reasonably definite specification that the FAR asks for, and the cap converts it into a budget limit without pretending every requirement is already known. If you are still at the stage of deciding what the build should cost, our breakdown of the four decisions that move the cost to build an app is a useful companion to that estimate.

What to put in the statement of work before you sign

The decision in front of you is narrower than fixed price or time and materials. It is whether the scope you are signing is definite enough to price, and if not, whether the contract states a ceiling, the consequence of reaching it, a rule for raising it, and the oversight that keeps you from hitting it. Ask the vendor to show you all four in writing. A vendor that will only offer an uncapped day rate, or only a fixed price on a scope nobody has tested, is telling you who it expects to carry the risk.

Timelines give you a sense of what the cap has to cover. A focused MVP typically takes us 6-10 weeks, and larger enterprise platforms 3-6 months depending on complexity, integrations and scope; a smaller MVP build is often the cleanest way to turn discovery findings into a priced first release.

If you are about to sign a statement of work for a custom platform and want a second read on whether its scope can honestly carry a fixed price, our custom software development team can scope a discovery phase with you and show you where the estimate is firm and where it is not.