Fixed price vs time and materials: which software contract fits

Fixed price vs time and materials is the first contract question most software buyers face, and it tends to be settled on the wrong grounds. Finance wants a fixed number. Engineering wants room to change. Neither preference says anything about the project itself. The right model depends on how much of the scope is known today and how much will only be found by building. This playbook covers when each fits, how fixed-price scope is kept from coming apart, the hybrid we propose most often, and the clauses that should worry you in either contract.

What each model actually buys you

A fixed-price contract buys certainty of spend against a defined scope. The vendor carries the estimating risk: if the work takes longer than planned, that is their problem, as long as the scope has not changed. You pay for that transfer, because every competent vendor adds contingency to a fixed quote. The vaguer the scope, the larger the contingency.

A time and materials contract buys flexibility. You pay for effort actually spent, usually monthly or per sprint, and you can change direction at any planning session without renegotiating anything. You carry the estimating risk. If the work takes longer, you pay for longer.

That is the whole trade. Certainty of cost against freedom to change. The rest of the contract exists to manage the side of the trade you did not choose.

	Fixed price	Time and materials
Who carries estimating risk	Vendor	Buyer
How scope changes	Written change request, repriced	Next sprint planning
Where the vendor protects margin	Contingency in the quote, narrow reading of scope	Team composition and seniority mix
Buyer effort	Heavy up front, lighter during delivery	Steady: a product owner every week
Best health signal	Change log and milestone acceptance	Working software every sprint, burn against roadmap
Typical failure	Disputes over what was in scope	Budget drift with nothing forcing a decision

When fixed price fits

Fixed price works when three conditions hold together.

The scope can be written down well enough that two independent teams would estimate it within a sensible margin of each other. Flows designed, integrations named with their APIs documented, roles and permissions listed, performance and security requirements stated rather than implied.

The requirements are unlikely to move during delivery. A compliance-driven build, where the scope is set by a regulator rather than by your own team, is a good example. So is rebuilding a product whose behavior is already defined by the version people use every day, or a second release on a platform the delivery team already knows.

Your organization can make decisions quickly. Fixed price punishes slow sign-off. Every week a milestone waits for acceptance is a week the vendor is carrying cost, and that pressure turns into friction on both sides.

Two of our Fixed Cost engagements show the shape. A patient engagement platform for a global healthcare organization ran for 12 months, and a pharmacy partner loyalty platform for a global pharmaceutical company ran for 9–12 months. In both, the workflows were well understood before build started. That, and not the size of the budget, is what made a fixed commitment sensible.

When time and materials fits

Time and materials fits when the thing being built is partly unknown and learning is part of the job.

A new product whose users nobody on the team has watched working. A platform that will run for years and change with the business. Data or AI work, where the quality of the underlying data is only known once someone has profiled it. A modernization where the legacy system’s real behavior lives in code nobody has read in ten years.

It also suits long programs. Our partner onboarding program for a large-scale energy enterprise ran for 24 months on time and materials. A fixed specification for two years of work, written in month one, would have carried either an enormous contingency or a document that everyone had stopped reading by month six.

The condition for time and materials sits on your side of the table. You need a product owner who owns the backlog, attends sprint reviews and is willing to say no. Without one, time and materials drifts, because nothing in the contract forces a choice between two things people want.

How fixed-price scope is actually protected

Most fixed-price failures are not estimating failures. They are scope failures: the contract said one thing, each side remembered something different, and the gap got argued about in week twenty. Four practices prevent most of it.

Discovery before the price

Do not accept a fixed price for a build that has not been through discovery. A quote produced from a slide deck and two calls is a guess with contingency on top. Paid discovery, typically about a week, produces user flows, a data model, an integration inventory and a written statement of what the first release does and does not do. The build price comes after, against that document.

Discovery is also the cheapest way to find out whether a vendor is any good. If the output is thin, you have learned that at a small commitment rather than a large one.

A scope document that names exclusions

The most useful section of a scope document is the list of things that are not included. Admin screens. Reporting. A second language. Offline mode. The integration with the finance system that someone mentioned once. Written exclusions end arguments before they start. A blanket “anything not listed is out of scope” does not, because nobody reads it until there is a dispute.

Change control that is fast and boring

Scope will change. What matters is whether the change process is quick enough that people actually use it. A workable process fits on one page: the request is written, the vendor responds with effort and schedule impact within a few working days, the buyer approves or declines, and the change log is reviewed at every milestone. If raising a change takes three weeks and a committee, people route around it with verbal agreements, and verbal agreements are what turn into disputes.

One rule makes fixed price far more livable: allow swaps. A new item of similar size can replace an unstarted item at no charge, provided both are recorded in the change log. The price stays fixed and the product can still respond to what users tell you.

Acceptance criteria per milestone

Tie payments to milestones, write the acceptance criteria before each milestone begins, and put a time limit on acceptance. Five or ten working days to accept or raise defects, after which the milestone counts as accepted. This protects the vendor from open-ended review, and it protects you, because the criteria were agreed before either side had a reason to reinterpret them.

The hybrid we recommend most often

For new products, the contract we propose most often is neither pure model. It runs in two stages.

Stage one is a fixed-price discovery. Short, bounded, with defined outputs: validated flows, a clickable prototype, architecture decisions, a prioritized backlog, and an estimate for the build with its assumptions written down. You own all of it, and you are free to take it to another vendor if you want to.

Stage two is the build, in one of two forms depending on what discovery found.

If discovery produced a stable, well-understood scope, the build is fixed price against it, with the change control described above.

If discovery showed that important questions can only be answered by putting software in front of real users, the build runs on time and materials with a budget ceiling and a prioritized backlog. The ceiling is a governance tool, not a price. When spend reaches an agreed threshold, both sides review what is left and decide what gets cut or whether the ceiling moves.

A third variant suits longer programs: a fixed-price first release, followed by time and materials or a dedicated development team for everything after launch. The first release is the part you can specify. What comes after is shaped by real usage, and pricing it as though it were already known only adds contingency.

The hybrid does not give you the benefits of both models for free. What it does is move the build contract decision to the point where you have the information to make it.

A decision framework you can apply

Answer these honestly. Each yes leans toward fixed price. Each no leans toward time and materials.

1. Could you hand the scope to two vendors and expect estimates reasonably close to each other?
2. Are the integrations named, documented and available to test against?
3. Will the requirements stay stable for the length of delivery?
4. Is delivery shorter than about six months?
5. Can your organization accept a milestone within one or two weeks?
6. Do your approvers value budget certainty more than the ability to change direction?

Mostly yes: fixed price, after discovery if you have not had one. Mostly no: time and materials, with a named product owner and a budget ceiling. Split down the middle: fixed-price discovery, then decide.

One question overrides the others. If nobody on your side can act as product owner for several hours every week, time and materials is risky whatever the other answers say. Either fix the scope or fix the ownership gap first.

Red flags in a fixed-price contract

• A fixed quote with no discovery and no written assumptions. The contingency is hidden, and scope will be read narrowly when it matters.
• No list of exclusions.
• Change requests priced at a premium, or with no committed response time. That is often where the margin gets recovered.
• Payment weighted heavily toward signature, with little tied to accepted milestones.
• Silence on code ownership. Ownership should pass to you as each milestone is paid, not only at the very end.
• A warranty period that starts at contract signature rather than at go-live.

Red flags in a time and materials contract

• No visibility of who is on the team, or a right for the vendor to swap people without notice. You are paying for effort, so you need to know whose effort.
• No working software at the end of each sprint. Status reports are not progress.
• No budget ceiling or review threshold. Without one, the only forcing function is the money running out.
• Team size that grows without a written request from you.
• Invoices you cannot reconcile against what each sprint delivered.
• A minimum commitment much longer than the work plausibly needs, with no exit clause.

When neither contract is the answer

If the software is the core of your business and you expect to change it every week for years, neither model is the long-term answer. You want engineers who stay. An outside team on either contract can help you start, and a build-operate-transfer arrangement can hand that team over, but the destination is ownership. We cover that decision in in-house vs outsourced software development.

At the other end, if the job is a few weeks of well-defined work, the overhead of either model is out of proportion. A short statement of work with a fixed fee and simple acceptance is enough. Nobody should sell you a governance framework for a three-week project.

How we contract

We offer three engagement models: Fixed Cost, Time and Materials, and Dedicated Team. We do not quote a fixed price for a build without discovery, and we say that in the first conversation rather than the third. For new products we usually propose a fixed-price discovery followed by whichever build model the evidence supports, with the reasoning written down so your approvers can see why. If you are weighing what that discovery would need to cover, what drives MVP development cost is a useful place to start.