Fixed price or time and materials: choosing a contract model

The real question is who carries the uncertainty

Every software estimate contains uncertainty: requirements not yet understood, systems that behave differently from their documentation, decisions nobody has made. The contract model decides who pays when that uncertainty turns into extra work.

With a fixed price, the supplier carries it and prices it in. With time and materials, you carry it and pay for the time actually spent. Neither model removes the uncertainty, so the useful questions are how much of it there is and who is best placed to manage it.

Fixed price fits work you can specify and accept

A fixed price works when the scope can be written down precisely and the result checked against acceptance criteria: a well-understood integration, the migration of a known set of applications, or features already designed and validated with users. Your budget is predictable, and the supplier has a reason to deliver efficiently.

The price includes a margin for risk, and a careful supplier sizes it to how much is unknown. Anything outside the written scope becomes a change request with its own price and delay. When the scope was vague, those change requests turn into negotiations that strain the working relationship.

Watch for a quieter risk as well. A supplier whose fixed price turns out too low has every incentive to cut testing, documentation and code quality, which are the parts you only notice later.

Time and materials fits work that will change as you learn

Under time and materials you pay for the time the team spends, usually at agreed rates per role. It suits discovery, new products whose requirements depend on user feedback, ongoing development and work inside systems nobody has fully mapped. You can change priorities every week without renegotiating the contract.

The risk sits with you: the total cost is open, and a poorly run team can spend a lot of time on the wrong things. Time and materials works only when you can see and steer the work, which means having these in place.

• A prioritized backlog that you own, with the most valuable work first
• A demo of working software at a fixed rhythm, such as every one or two weeks
• Reports that show where the hours went, by feature or milestone
• A budget forecast updated regularly and compared with what has been delivered
• The right to change the team size or stop at short notice

Hybrids often fit better than either pure model

Many projects are neither fully known nor fully open, and the common hybrids reflect that. Each one moves part of the risk back to whoever can manage it best.

• Phased fixed price: a short discovery phase at a fixed price, then a fixed price for the build based on what discovery found. You commit the larger amount only once the unknowns are smaller.
• Capped time and materials: you pay for time spent up to an agreed ceiling. The supplier warns you before reaching it, and scope is adjusted so the most important work lands under the cap.
• Fixed price per milestone: each milestone has its own scope, price and acceptance criteria, and both sides can reassess before the next one starts.
• Target price: an agreed estimate with shared savings below it and shared overruns above it, so both sides gain from efficient delivery.

Match the model to the phase you are in

One project can move between models. Discovery and early prototypes suit time and materials or a small fixed price, because their purpose is to reduce uncertainty. A build phase with clear designs and acceptance criteria can be fixed. Support and improvements after launch often return to time and materials or a monthly arrangement.

These questions help you decide for the phase in front of you. If you can answer yes to the first two and the last, a fixed price is realistic. If user feedback will reshape the work and you can steer it every week, time and materials or a hybrid will serve you better.

• Could you write acceptance criteria for every deliverable today?
• Do you know every system and data source the work touches?
• Will user feedback change what you build in the coming months?
• Do you have someone with time to prioritize and review work every week?
• Is a fixed budget more important to you than flexibility in scope?

Contract terms that protect you under either model

Whatever the pricing model, a few clauses do more to protect you than the pricing itself. Check that the contract covers each of them in plain terms.

• Acceptance criteria for each milestone, with a set period to accept or reject it
• A written change process: how changes are requested, estimated and approved, and by whom
• Your ownership of the code and intellectual property, and access to the repositories from the first day
• Named key people, and what happens if one of them leaves
• Termination terms that let you stop, keep the work done so far and receive a proper handover
• Warranty terms for defects found after acceptance

How a partner proposes the model tells you a lot

A partner that offers a fixed price before asking detailed questions has either priced in a large margin for risk or not understood the work. One that asks for open-ended time and materials without regular demos or reporting is asking you to carry the risk without the means to manage it.

A good answer explains which parts of the work are uncertain and proposes a structure that deals with them, often a first phase that reduces the unknowns before a firmer commitment. If you are weighing the models for a specific project, you can describe it through our Start a project form, and our engineers will reply with an honest next step.

FAQ