Fixed Price or Time and Materials: Which to Choose?

If you are about to hire a developer or an agency for custom software or a website, the quote will usually be either a fixed price or time and materials. This guide explains how each works, who carries which risk, and how to choose. You also get a list of questions and a clause checklist to bring to your next meeting.

We checked the sources below on 30 October 2026. They are buying rules and guidance from US and UK public bodies. They do not bind a private contract, but they show how large buyers think about risk. This is general information, not legal advice. Ask a qualified lawyer in your country to read any contract before you sign it.

The two models in plain words

With a fixed price, you and the supplier agree one price for an agreed scope. If the work costs more than planned, the supplier absorbs the difference. The US Federal Acquisition Regulation says a firm-fixed-price contract places maximum risk on the contractor, with full responsibility for all costs and for any profit or loss (FAR 16.202-1).

With time and materials, you pay for the hours worked at agreed rates, plus agreed costs such as licenses or hosting. UK government guidance for digital buyers sums up the risk split in one sentence: "A time and materials approach means you own more of the risk." That page was withdrawn on 31 December 2025 as out of date, so we use it only to show how a large buyer describes the models.

A third option is capped time and materials. You pay for time worked, up to a limit. In the same UK guidance, if the supplier reaches the cap before the work is finished, the supplier completes it at its own cost. If the work ends early, you pay only for the time used.

Who carries which risk

Cost overrun: a fixed price puts it on the supplier. Time and materials puts more of it on you. A capped contract puts it on you up to the cap and on the supplier beyond it.
The price of uncertainty: the UK guidance says a fixed price can be more expensive because the supplier owns most of the risk. Expect suppliers to add a margin for the unknowns.
Incentive to be efficient: FAR 16.202-1 says a fixed price gives the maximum incentive to control costs. FAR 16.601 says time and materials gives no positive profit incentive for cost control or labor efficiency, so it calls for appropriate oversight of the contractor.
Scope arguments: with a fixed price, every disagreement about what was included becomes an argument about money. With time and materials, you set priorities as you go, and you pay for changes of mind.

When a fixed price fits

FAR 16.202-2 says a firm-fixed-price contract suits work bought against reasonably definite functional or detailed specifications. It adds that the buyer must be able to set a fair price at the start, which is easier when the performance risks can be pinpointed and the cost effects reasonably estimated. In plain words: you can describe the finished result in writing, and the supplier can estimate the work with confidence, for example because it has built something similar before.

Examples that usually fit are a company website with a known list of pages, an integration with a documented API, and a data migration where the volume and the source system are known. A fixed price is a poor fit when the problem is still being discovered, for example an internal tool when nobody has mapped the workflow yet.

When time and materials fits

FAR 16.601 allows time and materials only when it is not possible, at the time of placing the contract, to estimate accurately the extent or duration of the work. It also requires a ceiling price that the contractor exceeds at its own risk, and a written finding that no other contract type is suitable. Those are rules for US federal buyers, but the logic helps anyone: time and materials is for uncertainty, and a ceiling is the safety belt.

For software built in short cycles, 18F goes further. 18F was a technology team of the US General Services Administration that GSA closed in March 2025, and its guide is still online at the time of writing. The guide to buying agile development recommends labor-hour contracts, meaning you buy developers' time rather than a defined product. It accepts time and materials with a ceiling on total spending as an alternative. It calls firm fixed price the historical default, chosen on the assumption that it reduces risk, and it recommends the other two types for agile work instead. Time and materials works well, it says, when the buyer can inspect and accept software quality all the time, and it makes it easier to stop giving work to a team whose output is not good enough.

The same guide suggests a base period of usually 6 to 12 months, with short options, and never more than three years in total. A private company can copy the idea: a short first term with a clear way to extend or stop.

A middle path: discovery first, then fix the price

The UK Service Manual describes a discovery phase that settles the problem before anyone builds. It says there is no set length, but around 4 to 8 weeks is typical, and a discovery is finished when you have decided whether to move on.

One sensible pattern is to pay for a short discovery with a cap, end it with a written scope and an estimate, then fix the price for the parts that are now clear. Keep the rest on capped time and materials. Our custom software page lists three ways to work together: a discovery sprint (workshops, a prototype and an estimate), a fixed-scope project, and an ongoing team.

Change requests, milestones and acceptance

Change requests

Whatever model you choose, write down how change works. A change request should say what changes, what it does to price and date, and who approves it, in writing, before the work starts. The UK example was strict. Each statement of work covered no more than a month of work. The price could rise by up to 20% only if the buyer approved in writing before the supplier charged above the agreed price. You do not need the same numbers. Copy the habit: small pieces of work and written approval.

Milestones

If you pay in stages, tie each payment to something you can check, such as an approved design, a working feature on a test site or a completed data import.

Acceptance criteria

Agree what done means before work starts. The UK Service Manual suggests writing acceptance criteria as outcomes a team can check, and often introducing the list with the words it's done when. The 18F guide gives a bigger example for each sprint: all code is complete, tested, accessible, deployed, documented and secure.

Questions to ask before you choose

Put these to every supplier. Our guide to questions before hiring an agency adds more.

Can we describe the finished result in writing today, page by page or screen by screen?
Which parts are unknown, and how will we find them out: a discovery, a prototype, a test?
Who decides priorities each week, and how fast can that person decide?
Will we see working software often enough to judge quality, for example a demo every week or two?
What is the most we can spend, and what happens when we reach 80% of it?
Which costs sit outside the price: hosting, licenses, paid apps, third-party fees?

Contract clause checklist

Scope: what is included, plus a list of what is not.
Price basis: a fixed total, a rate card with named roles, or a cap, and what the price covers.
Payment schedule: tied to deliverables you can check. Agree the invoice term in days. The UK guidance above required payment within 30 days of a valid invoice.
Change process: written request, estimate, approval before work starts.
Acceptance: criteria, a test period, and what happens when something fails.
Reporting and cap: for time and materials, weekly time summaries, spend against the cap, and a written warning at an agreed point, for example 80% of the cap.
Ownership and handover: code, designs, accounts and domain. Read our guide on who owns the code in a software project.
Ending the contract: how either side ends it, and what you receive when it ends.
Fix period: how long the supplier fixes defects after launch, written as a number of days.

Mistakes to avoid

Choosing a fixed price for a project you cannot yet describe, then arguing about every change.
Accepting time and materials with no cap, no reports and no demos.
Comparing quotes that cover different scopes. Give every supplier the same one-page brief.
Paying a large share up front with nothing you can check.
Leaving acceptance vague. A rule that depends on one person feeling satisfied cannot be tested.

Questions owners ask

Is a fixed price always the safer choice?

It is safer for your budget only when the scope is clear and complete. The UK guidance notes that a fixed price can cost more because the supplier owns most of the risk, and every change after signing becomes a negotiation. If the scope is still moving, capped time and materials can protect you better.

Can an agile project have a fixed price?

You can fix the price of a defined piece of work. The UK example used statements of work of no more than a month. The 18F guide notes that agile work does not start from a fully defined product, so it recommends labor-hour or time and materials with a ceiling over firm fixed price. One approach is a fixed price for each phase.

How do I stop a time and materials project from running over budget?

Set a cap, ask for regular reports, and see a working demo every one or two weeks. Agree the point at which the supplier must warn you. If the output is not good enough, you can stop assigning work.

Need a hand?

If you are unsure which model fits your project, send a short brief on our contact page. You can also read about our custom software and web development work.

Fixed price or time and materials: how to pay for a software or website project