Fixed price vs time and materials: which software contract should you choose?

Choose fixed price when the work can be specified in detail before it starts and is unlikely to change: a rebuild of a known system, a bounded integration, a migration. Choose time and materials when learning is part of the job: a new product, an AI feature whose feasibility is unproven, a live product that keeps evolving. Most real projects sit between the two, and a hybrid (a fixed-price discovery, a capped budget, or a monthly sprint arrangement) usually gives you more control than either pure model.

The choice matters more than it looks. A pricing model is not just a way of sending invoices: it decides who pays when an estimate turns out to be wrong, who pays when your idea of the product changes, and how much effort both sides spend arguing about which of those two things happened. This guide explains how each model works, the risks each one moves around, the hybrids in between, and the contract terms that matter more than the headline model.

The five models at a glance

Two different risks: the estimate and the scope

Most comparisons treat fixed price as 'low risk' and time and materials as 'high risk'. That is misleading, because there are two separate risks in any software project, and each model hands them to different people.

• Estimate risk: the work you described takes longer than expected. Integrations misbehave, data turns out messier than promised, a library has a bug, a performance target needs a different architecture.
• Scope risk: the work you described is not the work you need. Users behave differently from the plan, a competitor launches something, a regulator publishes new guidance, or the first demo shows that a workflow is wrong.

Fixed price moves estimate risk to the supplier but leaves scope risk firmly with you: if your understanding changes, you pay again through change requests. Time and materials leaves both with you, but makes scope risk cheap to act on, because changing direction is just a different item at the top of the backlog. The hybrids exist to split these two risks more sensibly.

Why software estimates are uncertain in the first place

Every pricing model is a response to the same fact: early software estimates are unreliable. The idea is old enough to have a name, the cone of uncertainty, popularised by Barry Boehm and Steve McConnell. It holds that an estimate made at the idea stage can be out by a factor of about four in either direction, and that the range only narrows as decisions are made and real work is done. The exact multipliers are partly judgement rather than measurement, but anyone who has delivered software recognises the shape.

The large-scale evidence points the same way. Research by McKinsey and the University of Oxford on more than 5,400 IT projects found that large IT projects ran 45% over budget and 7% over time on average, while delivering 56% less value than predicted. Bent Flyvbjerg and Alexander Budzier's analysis of 1,471 IT projects found an average cost overrun of 27%, but the average hid the real danger: one in six projects was a 'black swan' with an average cost overrun of 200%.

That second finding is the one to remember when you choose a contract. The risk in software is not that everything runs a little late. It is that a minority of projects go badly wrong, usually because something fundamental was misunderstood at the start. No pricing model removes that risk. A good one surfaces it early, while it is still cheap to act on.

Every contract prices uncertainty. The only question is whether you pay for it up front, as a premium on a fixed quote, or as you go, in the hours the work really takes.

How fixed price works in practice

A fixed-price quote is an estimate plus a margin for the supplier's risk. The supplier breaks the scope into pieces, estimates each piece, adds contingency for the unknowns it can see and a premium for the ones it cannot, and commits to the total. The more ambiguous the specification, the larger that buffer has to be, so a vague brief on a fixed price is usually the most expensive way to buy software.

Public procurement rules state the condition plainly. The US Federal Acquisition Regulation says a firm-fixed-price contract suits work where performance uncertainties can be identified and their cost impact reasonably estimated, and the contractor is willing to accept the risk. Put the other way round: if neither side can describe the uncertainties, a fixed price is a bet, not a plan.

What you need before you sign

• A specification detailed enough that a different team could build from it: user roles, screens or flows, business rules, integrations, data to migrate, and non-functional requirements such as performance, accessibility and security.
• Acceptance criteria for each deliverable, written as tests both sides can run, not as adjectives like 'intuitive' or 'fast'.
• A list of assumptions and exclusions. This is where most disputes start: who supplies content, which browsers and devices are supported, what happens if a third-party API does not behave as documented.
• A change-control process: how changes are requested, estimated, approved and scheduled, and who can approve them on your side.
• Milestone payments tied to accepted, working software rather than to dates or documents.

Where fixed price goes wrong

• The specification is a guess. If the product is new, the specification describes what you imagined before anyone used it. You then pay a fixed price for the wrong thing, followed by change requests for the right one.
• Incentives diverge. Once the price is fixed, every hour the supplier spends is cost to them. A good supplier still does careful work, but the contract quietly rewards reading requirements narrowly, and it rewards you for reading them broadly.
• Change becomes a negotiation. Small improvements that would take an afternoon turn into a priced request, an approval and a schedule change. Teams start defending the contract instead of improving the product.
• Quality is the hidden variable. When time runs short on a fixed price, the easiest thing to cut is what the acceptance tests do not check: test coverage, documentation, maintainability. You discover the cost later, in support.

How time and materials works in practice

Under time and materials you agree rates for the roles involved, a team shape, and a way of working: usually short iterations, a backlog you prioritise, and regular demos. You pay for the time actually spent. When the first users try the product and something needs to change, you change it, and the only negotiation is about priority.

The weakness is incentives again, from the other direction. The same US regulation notes that a time-and-materials contract gives the contractor no positive profit incentive to control costs or work efficiently, which is why it requires active oversight and a ceiling price. That is a fair description of the commercial model, though not of every supplier: plenty of teams on time and materials work hard to save their clients' money because they want the next project. But you should not rely on goodwill alone. Build the controls into the contract.

The controls that keep time and materials honest

• A budget envelope per month or per phase, with a written rule for what happens when it is close to being reached.
• A backlog you own and prioritise. The supplier advises; you decide what is worth building next.
• Working software every one or two weeks, shown in a demo, deployed to an environment you can use yourself.
• Readable time reports that map hours to backlog items, so you can see what each feature actually cost.
• A forecast, updated every iteration: how much of the remaining backlog fits in the remaining budget at the current pace.
• Access to the code repository and infrastructure from day one, so the work is visible and you can leave at any point with everything you paid for.

With those in place, time and materials is not an open cheque. It becomes a series of small, visible decisions about where the next fortnight of effort should go.

The hybrids, and when each one earns its place

Capped time and materials

A cap gives you the flexibility of time and materials with an upper bound on spend. The detail that matters is what the cap means. A hard cap means work beyond it is at the supplier's expense, which in practice makes the contract behave like a fixed price for the scope agreed at the start, and the supplier will price the cap accordingly. A soft cap means the supplier must stop and get your approval before going over, which keeps control with you without pretending the risk has disappeared. Ask which one you are being offered, and what happens to unfinished scope at the cap.

Phased fixed price

Phasing is the most practical answer to the cone of uncertainty. You pay a fixed price for a short discovery, typically a few weeks, whose output is a tested prototype, an architecture, a prioritised backlog and an estimate for the first release. That estimate is far more reliable than one made from a brief, so the first release can be fixed-priced without a large risk premium. Later releases are priced the same way, each with the benefit of everything learned so far. You can also stop after any phase, which is a better protection than any penalty clause. Our guide to scoping an MVP covers what a good discovery should produce.

Monthly sprints (fixed budget, variable scope)

Here the team, the duration and therefore the monthly budget are fixed, and the scope is what flexes. It turns the classic project triangle around: instead of fixing scope and arguing about time and money, you fix time and money and continuously decide which scope is worth the most. It suits product teams with a roadmap rather than a specification, and it is how most products are run once they are live. It needs a client who is willing to prioritise ruthlessly every sprint; without that, the team will be busy but the product will drift.

Support and evolution retainers

After launch, the work changes shape: security patches, dependency upgrades, monitoring, small improvements and the occasional urgent fix. A retainer with a defined monthly allowance of hours and agreed response times fits this better than either project model. Our software maintenance and support guide explains what such an agreement should cover.

Which model fits which project

A useful test: try to write the specification yourself, in enough detail that a team you have never met could build it. If you can do that for most of the product, a fixed price is reasonable. If you keep writing 'to be decided after we see it', you are describing a time-and-materials project, whatever the contract says.

A worked example, in weeks rather than money

Take a customer portal for a services business: sign-up and login, booking appointments, paying through an existing payment provider, a simple admin area, and an integration with the company's accounting system. Assume a team of a senior engineer leading, a second engineer and a part-time designer. Here is how the same project looks under four models.

• Fixed price from the brief. Nobody has seen the accounting system's API or the client's real booking rules. The supplier's honest estimate might be 10 to 16 weeks of team time, so it quotes near the top of that range plus contingency, and every rule discovered later becomes a change request.
• Phased fixed price. A two- to three-week discovery maps the booking rules, tests the accounting API, and puts a clickable prototype in front of real customers. The estimate for the first release narrows to, say, 11 to 13 weeks, and the fixed price for that release no longer needs a large buffer.
• Capped time and materials. The team works in two-week sprints against a soft cap of 13 weeks of team time. In week six, testing shows customers want to rebook rather than cancel; the team swaps a planned feature for that one without paperwork. If the work finishes in eleven weeks, you pay for eleven.
• Monthly sprints after launch. Once the portal is live, the team drops to a smaller shape, perhaps one engineer full time with the lead engineer part time, and works through a monthly backlog of improvements, fixes and upgrades.

The ranges above are illustrations of how uncertainty narrows, not a quote. To see how the drivers combine for your own project, try the software cost calculator or read our guide to what custom software development costs.

Contract terms that matter more than the pricing model

Two contracts with the same pricing model can behave completely differently depending on the clauses around it. Whichever model you choose, check these:

• Ownership of code and IP. You should own the code, designs and infrastructure accounts from the start, not on final payment. Check that open-source licences and any reused supplier components are listed.
• Access. Repository, cloud accounts, error monitoring and the project board in your name, with the supplier invited in, not the other way round.
• Termination for convenience with a handover. You should be able to end the contract with reasonable notice, pay for work done, and receive everything needed for another team to continue.
• Acceptance process. How long you have to test a delivery, what counts as a defect, and what happens if you do not respond.
• Warranty period. How long defects in delivered work are fixed at no extra cost, and how a defect is distinguished from a change.
• Key people. Who will actually do the work, and what happens if they leave. A senior engineer on the proposal who never appears on the project is a common complaint.
• Reporting. What you will see each week or sprint: progress, hours, risks and the updated forecast.
• Data protection and security. Where data is stored, who can access production, and how secrets and personal data are handled.

Questions to ask a supplier before you sign

1. Which pricing model would you choose for this project, and why? A supplier that only offers one model will fit every project into it.
2. What are the biggest unknowns in our project, and how does your estimate account for them?
3. On a fixed price: what is excluded, and what does a typical change request cost in time and turnaround?
4. On time and materials: what controls do you propose, and how will we know each month whether the budget still covers the backlog?
5. What happens if we want to stop after the first phase?
6. Who will we talk to day to day, and will they be the people writing the code?

For a wider checklist covering references, technical due diligence and red flags, see how to choose a software development company and our software development outsourcing guide.

When none of these models is the answer

Sometimes the honest conclusion is not to commission a build. If an off-the-shelf product covers most of what you need, configuring it is usually faster and cheaper than any custom contract, and the pricing question becomes a licensing question. Custom software earns its cost when the process it supports is a genuine advantage, or when no product fits without painful workarounds. Our comparison of custom software and off-the-shelf products walks through that decision.

It is also worth being wary of a fixed price that looks too good. A low fixed quote on a vague scope usually means the supplier plans to recover the difference through change requests, or has not understood the work. Either way, the number you signed is not the number you will pay.

How Authect approaches this

We offer three cooperation models: fixed-price projects, monthly sprints, and support and evolution. Which one we suggest depends on how much of your scope can be pinned down today, and we will say so plainly, including when the answer is a short fixed-price discovery before anyone commits to the full build.

Because Authect is founder-led, the people who scope and estimate your project are the people who build it, so there is no gap between what was sold and what gets delivered. Every project is led by a senior engineer. We use AI to speed up delivery, and an engineer reviews every line before it ships. You own the code, infrastructure and designs from day one, which means you can change model, or change supplier, without losing anything. If you want a second opinion on which model fits your project, talk to the founders.