Fixed price vs time and materials
Both contracts can deliver good software. They differ in who pays when the work turns out harder than the document said.
The short answer
Sign a fixed price when the scope is written down to the screen, and sign time and materials when you are still learning what the product should do.
A contract does not remove risk. It moves it. Under a fixed price the vendor carries the surprise, and prices for it. You carry it under time and materials, and pay only for what happened.
So the real question is not which is safer. It is whether anyone can describe the finished thing accurately today.
Side by side
Compared on what actually changes during a build, not on how the invoices are formatted.
| Dimension | Fixed price | Time and materials |
|---|---|---|
| Who absorbs a surprise | The vendor, inside the agreed number | You, as extra hours on the invoice |
| What you must know up front | Nearly everything: screens, rules, integrations | The first few weeks of direction |
| Changing your mind | A change request, priced and signed | A conversation, then a new ticket |
| What the vendor optimises for | Finishing inside the number | Staying useful for longer |
| Where it goes wrong | Arguments about what "done" meant | Spend drifts with nobody watching |
| Your job during delivery | Guard the scope and sign changes | Prioritise weekly and read the burn |
| Best fit | A rebuild of something that exists | A product still finding its shape |
| Worst fit | Anything with the word "discovery" in it | A board that needs one number today |
- UnknownsEvery build starts with them
- SpecificationFixed price prices this document
- BuildWhere the unknowns actually surface
- SurpriseVendor eats it, or you pay for it
- LaunchSame software, different argument
The unknowns are identical in both. Only the person holding them changes.
Fixed price
Where it wins
- You get one number to take to a board or an investor, and it does not move.
- The vendor is paid to be efficient, because slow work costs them rather than you.
- Procurement teams can compare bids on a like-for-like basis.
- It forces the specification conversation early, which is usually worth having anyway.
Where it hurts
- Every quote carries padding for the unknowns, because the vendor is underwriting them.
- Changing your mind gets expensive and slow, so teams stop asking for changes that would improve the product.
- A vendor losing money on a fixed bid has an incentive to argue that your request was never in scope.
- Quality drops quietly at the end, where cutting a test suite is invisible to you and saves them a week.
Time and materials
Where it wins
- You can change direction on a Monday without a lawyer.
- You pay for real work rather than for a vendor's estimate of its own risk.
- Priorities can follow what users do, which is the point of building software at all.
- Stopping is easy. If the idea is wrong, you close it down and keep what was built.
Where it hurts
- There is no number to promise anyone, which makes budget approval harder.
- It rewards nobody for finishing. Without a strong owner on your side, work expands.
- You need someone internal who can prioritise weekly and read a burn rate.
- A weak vendor stays busy rather than useful, and the invoices look identical either way.
How to choose
- Choose fixed price if you can hand a vendor a document and point at the screens, the rules and the systems it must talk to.
- Choose fixed price if the money must be approved once, by people who will not revisit it.
- Choose time and materials if the honest answer to "what does it do" is still changing week to week.
- Choose time and materials if you have a product owner who will sit in the weekly call and cut things.
- Choose a paid diagnostic first if the work means changing software that already exists. Nobody can price a codebase they have not read.
- Choose neither if the real problem is that two people in your business disagree about what is being built. A contract will not settle that, and both models will bill you while you argue.
Which contract fits this project?
Answer for the project in front of you, not for how your company usually buys.
Can you show a vendor what the finished screens look like?
Who decides what gets built next month?
What does your finance team need?
How much of this touches systems you already run?
Every outcome
- Fixed price
- You can describe the finished product and the systems it touches. Price it once and hold the scope.
- Time and materials
- The product is still moving. Buy capacity, review priorities weekly, and keep the option to stop.
- A diagnostic, then a price
- The work lives inside software that already exists. Two weeks of reading it turns guesses into a number.
Builds we scoped and delivered
Questions buyers actually ask
01Can one project use both models?
Yes, and splitting by phase is the most common arrangement that works. Put a fixed price on the specified parts, such as a defined integration or a rebuild of an existing screen. Run the discovery work on time and materials. That split needs a written boundary, because the argument always happens where the two meet.
02Why do fixed-price quotes vary so much between vendors?
Most of the gap is risk pricing, not effort pricing. A vendor who has built the same thing before knows which parts are hard and pads less. A vendor guessing pads more, or bids low and plans to recover it through change requests. Ask each bidder which part they think is riskiest; the answers tell you who has read the brief.
03What stops time and materials from running forever?
A written stop condition, agreed before the first invoice. Set a budget ceiling that triggers a review rather than an automatic extension, and agree what the project must demonstrate by then. Without that, the model has no natural end and both sides drift.
04Does fixed price mean we get less flexibility?
It means flexibility has a price and a signature. Small changes usually get absorbed. Anything touching the data model or an integration becomes a change request. Teams under a fixed price often stop suggesting improvements to avoid the paperwork, and that is the hidden cost nobody puts in the contract.
05Which model is better for AI work?
Time and materials fits most AI work, because the accuracy you can reach is unknown until you test against real data. A fixed price is reasonable once you have a working prototype and a scored test set, since the remaining work is engineering rather than research. Quoting a fixed price for accuracy nobody has measured yet is how AI projects end in a dispute.
Related
- build vs buy software →Decide this before you decide how to pay for it.
- staff augmentation vs outsourcing →One buys people, the other buys an outcome.
- where we do this work →Custom builds, scoped and priced after we read the problem.
- a compliance platform we built →Right-to-work checks against a government API.
