Fixed price vs time and materials: choosing a software contract
A fixed price fixes the scope, not the outcome. Time and materials fixes the rate, not the bill. Here’s where the risk sits in each, and the hybrid that suits most software projects.
By the METHODSS team
The first question
On this page
What each model actually fixes
The names suggest a simple trade: certainty on one side, flexibility on the other. In practice each model fixes one number and lets another move, and the question that matters is which number your project can afford to let move.
Under a fixed-price contract the supplier agrees to deliver a defined scope for an agreed sum. The US Federal Acquisition Regulation, which has some of the clearest public definitions of both models, describes a firm-fixed-price contract as one that “provides for a price that is not subject to any adjustment on the basis of the contractor’s cost experience in performing the contract.” The price is fixed; the scope is fixed with it, because the price was calculated from it.
Under time and materials (T&M) you pay for the hours actually worked at agreed rates, plus any materials or third-party costs at cost. The FAR describes it as buying work on the basis of “direct labor hours at specified fixed hourly rates that include wages, overhead, general and administrative expenses, and profit”, plus the actual cost of materials. The rate is fixed; the total is not.
| Fixed price | Time and materials | |
|---|---|---|
| What is fixed | The total price and the scope it was calculated from | The hourly or daily rates |
| What moves | Scope, through change requests that are priced separately | The total cost, with the hours worked |
| Who carries overrun risk | The supplier, who prices that risk into the quote | You, unless the contract adds a cap |
| How change is handled | A change request, a new estimate and a signature | Re-prioritise the backlog; the cost follows the work |
| What you need up front | A detailed, stable specification | A clear goal, priorities and someone to steer |
| Best for | Short, well-understood work | Products that will change once people use them |
Neither model is cheaper by nature. A fixed price moves risk to the supplier, and a competent supplier charges for carrying it. Time and materials keeps that risk with you, and rewards you when the work turns out simpler than feared.
When a fixed price works
A fixed price is the right choice when the work can be described completely before it starts and is unlikely to change while it is being done. The FAR puts the condition plainly: a firm fixed price suits work bought “on the basis of reasonably definite functional or detailed specifications … when the contracting officer can establish fair and reasonable prices at the outset”.
In software, that is true more often than people expect, as long as the piece of work is small and well bounded:
- A discovery or planning phase with a defined output: workshops, a prioritised backlog, an architecture outline and a written estimate.
- A technical audit of an existing codebase, cloud account or set of integrations, delivered as a report with findings and a plan.
- A well-specified integration between two systems with documented APIs, where the data mapping can be agreed in advance.
- A marketing website whose pages, content and design system are agreed before the build starts.
What these have in common is that “done” can be written down as acceptance criteria before the first line of code. If you can’t do that yet, a fixed price doesn’t remove the uncertainty: it hides it inside the supplier’s contingency, where you pay for it either way.
The hidden costs of fixing the price
A fixed price feels safe because the number on the contract can’t go up. Three costs sit behind that number.
The risk premium
A supplier quoting a fixed price for uncertain work has to protect itself against the version of the project where everything goes wrong. That protection is a contingency built into the price. If the project goes smoothly, you have paid for insurance you didn’t use.
Change becomes a negotiation
Software requirements change once people see working screens; that is the point of showing them. Under a fixed price every change is a change request: a new estimate, a review and a signature, often for small adjustments. Teams start to avoid asking for improvements because the process costs more than the change.
Incentives drift away from quality
When the price can’t move, the supplier’s margin depends on doing the minimum that meets the letter of the specification. Martin Fowler describes the underlying problem: “The biggest problem with the fixed scope contract is it immediately pits the client and contractor on opposite sides where they are fighting each other about whether something is a change and who should pay for the change.” Arguments shift from “what does the product need?” to “what did the contract say?”. He also warns of suppliers who “deliberately low-bid the fixed price, with the explicit plan of making a profit on change requests”.
When time and materials works
Time and materials suits work where the goal is clear but the route is not: a new product, a platform that keeps evolving, or AI features whose quality has to be measured and improved before anyone can say how long they will take. Even the FAR, written for buyers who are cautious by design, allows it “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.”
The flexibility is real. You can change priorities every sprint, stop work that isn’t paying off and spend more on what is. The risk is also real: without controls, the total cost follows the hours, and the hours can drift. The FAR is frank about why: T&M “provides no positive profit incentive to the contractor for cost control or labor efficiency”, so it requires “appropriate Government surveillance of contractor performance” and a ceiling price “that the contractor exceeds at its own risk”.
Good T&M contracts add the controls that a fixed price gets from its specification:
- A ceiling (a not-to-exceed amount per phase or per month) that can only be raised in writing.
- A short planning cycle, such as two-week sprints, with priorities agreed at the start of each.
- Working software every week, so progress is judged on what you can click through, not on reported hours.
- A written weekly summary of hours, budget used, risks and decisions needed.
- The right to stop at the end of any sprint, with everything built so far handed over.
The hybrid most software projects should use
For most custom software, the honest answer is neither model on its own. Fix the price of the part you can describe, then pay for the rest as it is built, with limits you control.
- A fixed-price first phase. Discovery and planning with a defined output: the problem, the users, the first release, an architecture outline, and an estimate with every assumption written down. You can walk away with the plan.
- Capped time and materials for the build. Delivery in short sprints against the prioritised backlog, with a budget ceiling per phase and a working demo every week.
- Milestone checkpoints. At the end of each phase, compare what was delivered with the plan and decide whether to continue, change direction or stop.
This is sometimes described as fixing time and budget and letting scope flex: the team commits to the most valuable features that fit, in priority order, rather than to an exhaustive list. It matches how the Agile Manifesto puts it: “Customer collaboration over contract negotiation.” Martin Fowler made the same point about agile contracts two decades ago: you can fix the price, but “what it really means is that you can’t come up with a fixed scope contract.”
Even US government guidance describes this path. The US Digital Service’s TechFAR Hub notes that forcing a fixed price onto uncertain work “could force the contractor to build in unnecessary contingencies that would result in a higher price”, and encourages agencies with a hybrid contract “to move to FFP when pricing history is established and when the pace as an integrated team is set.”
It is also how we work at METHODSS: most custom software and SaaS projects start with a fixed-scope first phase, so cost and outcome are agreed before larger commitments, followed by delivery in two-week sprints. The stages are described in our approach.
Dedicated team, team extension or project delivery?
Pricing is one decision; who manages the work is another, and buyers often mix the two up. The same T&M rates can buy very different arrangements:
| Model | Who manages the work | Usual pricing | Fits when |
|---|---|---|---|
| Project delivery | The supplier, against an agreed scope and plan | Fixed price, or a fixed first phase then capped T&M | You want an outcome delivered and have no team to manage it |
| Dedicated team | The supplier’s delivery lead, with your product owner setting priorities | Monthly, per team | You need a whole product team for months, not weeks |
| Team extension (staff augmentation) | You: the engineers join your team, rituals and codebase | T&M per person | You have engineering leadership and need capacity or a skill |
Staff augmentation only works if you already have someone who can direct engineers day to day. If you don’t, buy a delivery arrangement instead, where the supplier is accountable for the result, not just for the hours.
What to put in the contract, whichever model you choose
The pricing model is one clause. These matter at least as much, and are cheaper to agree before the work starts than after:
- Ownership. Code, designs, documentation and cloud accounts belong to you from the start, not on final payment.
- Definition of done. Acceptance criteria for each deliverable, including tests, documentation and deployment.
- Change control. How changes are requested, estimated and approved, and who can approve them.
- Rates and limits. The rate card, any ceiling per phase, and what happens when it is reached.
- Reporting. What you receive every week: progress, budget used, risks and decisions needed.
- Warranty. How long defects found after acceptance are fixed at no charge.
- Exit. Notice period, handover of code and credentials, and help for the next team.
A quick way to decide
Answer four questions about the work in front of you:
| Question | If yes | If no |
|---|---|---|
| Can you write acceptance criteria for every feature today? | A fixed price is realistic | Fix only the discovery phase |
| Will requirements stay stable once users see the product? | Fixed price or fixed milestones | Capped T&M with short sprints |
| Is the deadline set by an outside event (a launch, a regulation)? | Fix time and budget; let scope flex | Optimise for value, not the date |
| Do you have someone who can steer the work every week? | T&M or a dedicated team will work | Choose project delivery with a fixed first phase |
If the answers are mixed, which is common, start with the hybrid: a fixed first phase that turns the open questions into a plan, then a build you can steer and stop.
Sources
Every source below was read on 26 October 2026. Prices and product details change; check the current page before relying on a figure.
- Acquisition.gov: FAR 16.202-1: Firm-fixed-price contracts, description
- Acquisition.gov: FAR 16.202-2: Firm-fixed-price contracts, application
- Acquisition.gov: FAR 16.601: Time-and-materials contracts
- Acquisition.gov: FAR Overhaul: Part 16
- GovInfo: Executive Order 14402: Promoting Efficiency, Accountability, and Performance in Federal Contracting
- US Digital Service: TechFAR Hub: Contract Design
- Martin Fowler: Fixed Price
- Martin Fowler: Fixed Scope Mirage
- Martin Fowler: Scope Limbering
- Agile Manifesto authors: Manifesto for Agile Software Development