Fixed Price or Time and Materials, Honestly
One of these models transfers risk to the supplier and quietly charges you for it. The other transfers it to you and depends on trust. Neither is the right default, and the choice is not really about money.
By NinjaNext TechnologiesPublished 4 min read
Key takeaways
- Fixed price buys certainty, paid for with a risk margin and an argument about scope.
- Time and materials buys flexibility and requires you to stay involved.
- The right model depends on how well the work is understood, not on budget size.
- A fixed price on vague requirements is the worst of both: padded and still disputed.
Most people asking this question have been told the answer already, usually by whoever prefers one of the models. It is worth setting out what each actually does, because both are legitimate and the failure modes are specific.
What a fixed price really is
A fixed price is an insurance policy. The supplier agrees to absorb the risk of being wrong about effort, and prices that risk into the number. If the work is well understood, the margin is small. If it is not, the margin is large, because it has to cover the worst plausible case.
You do not see the margin. You see one figure, and because it is one figure it feels like good value when the project goes badly and poor value when it goes well. That asymmetry is the deal.
The second effect is subtler and does more damage. Once a price is fixed, every conversation about change becomes a negotiation. A reasonable improvement spotted in week three stops being a good idea and starts being a variation to be priced, and both sides begin reading the specification like a contract, because it is one.
What time and materials really is
Time and materials removes the margin and the argument, and puts the risk on you. You pay for what happens. If the work goes well you keep the saving; if it does not, you carry it.
This only works with two things in place. You need visibility, meaning something demonstrable at a regular interval rather than a status update. And you need the ability to stop, which is the real protection: an arrangement you can end at the end of any month is one where the supplier has to keep earning it.
Where it goes wrong is not usually dishonesty. It is drift, where nobody is forcing the question of whether the current piece of work is still the most valuable one. That is a governance failure, and it is yours to prevent.
The question that actually decides it
Not budget. Not size. The question is how well the work is understood before anyone starts.
- A defined piece with a clear edge, such as a payment integration or a store release, is understood well enough to be fixed, and should be.
- A first version of a new product is not understood, by anyone, including you. Fixing its price means fixing a guess, and the guess gets padded.
- Ongoing work on a live product is understood but open-ended, which suits a capped monthly arrangement.
- A takeover of someone else's code is unknown until it has been read, which is why that reading is a separate, bounded piece.
This is why scoping work properly changes more than it appears to. Scope is not paperwork; it is the thing that decides which commercial model is available to you at all.
The arrangement that usually works
In practice the useful answer is rarely one or the other for a whole project. It is a fixed, bounded first piece, priced with confidence because it is small and defined, which produces a plan. Then the larger work under whichever model the plan has now made honest.
That structure has a property neither pure model has: an early, cheap exit. You find out what a supplier is like to work with while the commitment is still small, and you find out what the project really involves before anyone has signed up to a number that depends on not knowing.
Our own preference, stated once: fixed for anything with a clear edge, and a bounded discovery piece before anything that does not have one. We would rather tell you the shape is wrong than fix a price on a guess and defend it for three months.
The terms that matter more than the model
Whichever you choose, a few clauses decide more than the pricing does. Who owns the code, stated plainly, with repositories under your accounts from day one. What happens at the end, including a handover somebody other than the author has actually performed. How changes are agreed, in a sentence, before the first one arrives.
Projects rarely fail on the commercial model. They fail on the absence of those three. A fixed price with no agreed handover still leaves you dependent on the supplier afterwards, and a flexible arrangement with clear ownership and a monthly exit is far safer than a fixed one without them.
It is also worth deciding in advance how you will judge progress, because both models are vulnerable to the same thing: a long stretch where effort is visible and outcomes are not. Something working, demonstrated at a regular interval, protects you under either arrangement, and its absence is the earliest warning you will get.