The contract model is usually treated as a procurement detail, settled after the vendor is chosen. It is not a detail. It determines how both sides behave for the rest of the engagement: what gets raised early, what gets quietly absorbed, what counts as a problem, and who pays when the work turns out to be different from the document that described it. We sign both kinds of contract. This is an honest account of what each one does to the people signing it.
What a fixed bid actually buys
A fixed bid buys certainty about one number. That is a real thing to want. Budget is approved once, a board or a lender sees a defined commitment, and procurement can compare bids on a single axis. If the outcome matters more to you than the process, and the process is genuinely predictable, a fixed bid is the correct instrument.
What you pay for that certainty is a risk premium. The vendor is absorbing the difference between their best case and their worst case, so a competent one prices somewhere near the pessimistic end and adds margin for the parts of the specification they do not yet understand. You are not buying the expected cost of the work. You are buying an insurance policy against the work costing more, underwritten by a party who knows less about your business than you do.
The premium is not the expensive part
Once the price is fixed, the vendor's economics invert. Every hour spent on your project is a cost to them and every hour not spent is margin. That single fact reshapes every conversation that follows. Ambiguity in the specification is now worth money, so it gets read narrowly. A better idea discovered in week six is now a threat to margin rather than an improvement, so it arrives as a change order rather than as a suggestion. Testing, documentation, and the unglamorous operational work at the end of a project are the easiest places to recover a slipping budget, and they are exactly the parts you cannot evaluate until you are living with the system.
- The specification has to be detailed enough that both parties genuinely mean the same thing by it
- Someone on your side has to be able to say no to changes, because every change is now a commercial event
- Acceptance criteria have to be written before work starts, not agreed at the end
- The vendor has to have built something close enough before to price it without guessing
- Any dependency you own (data, access, sign-off, a third-party API) becomes a contractual excuse if it slips
What time and materials actually buys
Time and materials buys the right to change your mind. Direction can shift in a week without a commercial negotiation, discoveries get reported instead of hidden, and the vendor has no reason to argue about whether something was in scope. On work where the requirements are genuinely being uncovered as the work runs, this removes an enormous amount of friction.
The cost is that all the risk moves back to you, and it arrives without a schedule. The vendor is paid the same whether the project finishes in four months or nine. That is not an incentive to waste money, but it is the absence of an incentive to stop. Time and materials has no built-in moment where anyone is forced to ask whether the remaining work is worth what it will cost. Spend continues for as long as invoices keep being approved, and the decision to end it has to come from someone on your side who is willing to make it.
- Velocity reports that describe activity rather than working software in production
- A backlog that grows faster than it is burned down, month after month
- Nobody able to state what the remaining work costs, only what it cost so far
- Refactoring and infrastructure work that is never tied to a user-visible outcome
- A product owner on your side who has other jobs and attends every third session
Time and materials works when you have an engaged, available decision-maker and a relationship with enough history that both sides trust the invoices. It works badly as a first engagement with a vendor you have not worked with, because you are being asked to extend trust before you have any evidence.
Why the change-order fight is designed in
Buyers who have been through a bad fixed-bid project usually conclude the vendor was acting in bad faith. Occasionally that is true. Far more often, both parties behaved rationally inside a structure that made conflict inevitable.
Consider a statement of work containing the sentence: the system will import customer data from the existing platform. The vendor priced one import routine against one table. Discovery finds three customer tables that disagree with each other, account owners stored as free text, and a rule about which duplicate wins that lives only in the head of the person who has done the merges by hand for a decade. The buyer reads that sentence as obviously covering the work. The vendor priced the sentence as written. Both readings are defensible and neither party is lying. The contract asked a document to carry more precision than anyone had when it was signed.
The model we prefer: incremental fixed scope
There is a third option, and it is the one we use for most operational software. Rather than fixing the price of a program nobody can specify yet, fix the price of the next increment: an assessment, or one bounded release that puts a real workflow in front of real users. When it lands, the following increment is priced against something that exists rather than against a document.
- 1
Agree a small first increment with a fixed price, a fixed duration, and a defined output you can act on.
- 2
Deliver it. The output is working software or a decision, not a deck.
- 3
Reprice the next increment using what the first one revealed about the data, the integrations, and the people.
- 4
Approve, adjust, or stop. Stopping is a supported outcome, not a failure state.
- 5
Repeat until the remaining work is no longer worth its cost, which is a decision you get to make roughly every six to ten weeks.
This works because the risk premium collapses. Pricing eight weeks of defined work is a forecast; pricing eighteen months of undefined work is a bet, and bets are expensive. It also removes the incentive to hide problems: if a discovery in week three changes what the next increment should be, saying so early is the only way to price it correctly, and the vendor is not defending a margin that a disclosure would destroy.
We should be plain about our own interest. This model suits us: it keeps engagements running while the work is worth doing, gives us a clean exit when it is not, and spares us the argument about whether a sentence written before discovery covers what we just found. It is a preference with reasons, and the reasons point the same direction for both sides, which is roughly the test any contract model should pass.
Capped time and materials and shared-risk variants
Two hybrids come up often enough to be worth naming, and both are better than their reputation if you understand what they actually do.
Capped time and materials
You pay for hours actually worked, up to a ceiling. The buyer gets downside protection without renegotiating scope every time direction changes. The failure mode is that the cap becomes the budget: a vendor approaching the ceiling manages toward it, and you still carry the scope discipline a fixed bid would have imposed. Caps work best set per increment, so hitting one is a review rather than a crisis.
Shared risk and target cost
Both parties agree a target cost and split the overrun or the saving on a stated ratio. Done properly it aligns everyone to the same number, but it requires open books, a buyer-side finance function willing to read them, and an existing relationship. Without those, the target becomes a fixed bid with extra paperwork.
Whichever model you choose, the terms that matter most are rarely the price. Acceptance criteria, ownership of code and documentation, notice periods, and what happens to work already delivered if you stop are the clauses you will care about if the engagement goes badly. Those are points to take to your counsel, not to settle in a sales conversation.
Choosing between the models
| Model | What it optimizes for | Where it breaks | When to use it |
|---|---|---|---|
| Fixed bid | Budget certainty for the buyer and margin protection for the vendor | Discovery-heavy work, where every finding becomes a commercial negotiation and ambiguity is read narrowly | Fully specified work with stable requirements, a hard approval gate, and a vendor who has built the same thing before |
| Time and materials | Flexibility and the ability to change direction without a negotiation | When nobody owns the stopping decision, spend continues as long as invoices are approved | Ongoing support, embedded engineering, and work where you have a strong, available product owner |
| Incremental fixed scope | Pricing at a granularity small enough to be honest, with a real exit at every increment | When the buyer cannot make decisions between increments, or needs one number for the whole program up front | Operational software where the requirements are uncovered as the work runs |
| Capped time and materials | Buyer downside protection without repricing scope on every change | The cap becomes the target, and the buyer still carries the scope discipline | A bounded piece of work with roughly known scope where you want a ceiling |
| Shared risk / target cost | Aligning both parties to the same cost outcome | Without open books and mature procurement, it degrades into a fixed bid | Long programs with an established relationship and a finance function on both sides |
None of this is an argument against fixed bids. If the requirements are genuinely stable (a defined integration between two documented systems, a migration you have already scoped, a rebuild of something whose behaviour is fully known), take the fixed price. You pay a premium for the certainty, the vendor earns it by carrying real risk, and neither side argues, because the document actually describes the work. The mistake is not using fixed bids. It is using one where the specification is a hopeful summary of something nobody has examined yet.
Common questions
- Is a fixed bid safer for the buyer?
- It is safer for the budget and riskier for the outcome. You have transferred cost risk to the vendor, but you have also given them a financial reason to deliver the minimum defensible reading of the specification. On well-specified work that trade is worth making. On work where the requirements are still being discovered, you are usually trading a known number for an unknown result.
- Why will a vendor not quote a fixed price before discovery?
- Because the number would be fiction. Without knowing the state of the data, the behaviour of the systems being integrated, and who actually makes decisions, any figure is either padded heavily or set low with the intention of recovering the gap through change orders. A vendor who quotes confidently on a two-page brief is telling you something about how the rest of the engagement will run.
- How do we control spend on time and materials?
- Put a decision point on the calendar rather than relying on reports. Fix the scope and price of the next few weeks, require working software in a real environment at the end of it, and treat continuing as an active choice rather than the default. Caps help, but only if they are set per increment; a single cap on a twelve-month engagement just relocates the deadline.
- What does incremental fixed scope cost compared with one fixed bid?
- Usually less in total, because you are not paying a risk premium on eighteen months of unknowns, and because you can stop paying for work that turns out not to matter. It costs more in attention: someone senior on your side has to review and approve each increment. If nobody has time for that, the model does not work and you are better off with a specification and a fixed price.
- Can the contract model be changed mid-engagement?
- Yes, and it often should be. Discovery and the first release frequently run as fixed increments, then longer-term support moves to time and materials once both sides know each other and the system is stable. Sequencing the models deliberately is more useful than picking one for the whole relationship. How that transition is documented is a question for your counsel.