Fixed price or time and materials: which contract actually protects you

When you commission software you will usually be offered one of two contracts. Fixed price: an agreed scope for an agreed amount. Time and materials: you pay for the hours actually worked, usually against an estimate.

Most buyers pick fixed price by reflex, because a fixed number feels like protection. Sometimes it is. Sometimes it is the most expensive way to buy software. The difference is not the contract. It is how well you know what you are building.

What fixed price really fixes

A fixed price fixes the cost of the scope that was written down. That last part is the whole story.

If the scope is precise, meaning every screen, every user role, every integration and every rule is described, fixed price works well. You know what you pay, the supplier carries the risk of their own estimate, and both sides can plan.

If the scope is vague, fixed price moves the uncertainty somewhere else instead of removing it:

• Into the price. A supplier quoting a fixed amount for an unclear scope adds a margin for the unknowns. You pay for the risk whether or not it happens.
• Into change requests. Anything not written down is extra. The first months of the project turn into arguments about whether something was "obviously included".
• Into quality. When the money is fixed and the work grows, something gives. It is usually testing, polish or documentation, which are exactly the things you only notice after launch.

Fixed price protects you from overruns on a known scope. It does not protect you from not knowing the scope.

What time and materials really risks

Time and materials puts the estimate risk on you. If the work takes longer, you pay more. That is the part everyone sees.

What people miss is what you get in exchange: the ability to change your mind cheaply. When you learn something in week four, you can change direction without renegotiating a contract. For a product that is still being discovered, which describes most new products, that flexibility is often worth more than cost certainty.

Time and materials goes wrong in predictable ways, and each one has a fix:

• No visibility. You are billed hours but cannot see what they produced. Fix: regular builds you can actually open, not status reports.
• No ceiling. The estimate drifts and nobody says so until the invoice arrives. Fix: a budget cap per phase, with the supplier obliged to warn you before approaching it.
• No definition of done. Work continues because nobody decided when it was finished. Fix: agree what "finished" means for each phase before it starts.

The model that usually works best: both, in sequence

For most projects, the best answer is a combination:

1. A short, fixed-price discovery phase. A defined amount to turn the idea into a written scope: screens, roles, integrations, assumptions and what is explicitly out.
2. A fixed-price build of that scope, now that it can actually be priced honestly.
3. Time and materials for everything after: changes, improvements and the things you learn once real users arrive.

This gives you cost certainty where the work is known and flexibility where it is not. It also gives you a clean exit after step one: you own a written scope and can take it to anyone.

Questions to ask whichever you choose

• What exactly is fixed? Get the scope attached to the contract, not summarised in it.
• How are changes priced? A rate, a process and who approves.
• What happens if the estimate is wrong? On fixed price, who absorbs it. On time and materials, when you are told.
• What do I own if we stop halfway? The code, the designs and the accounts, at every stage, not just at the end.

The contract that protects you is the one that matches what you actually know. If you can describe the product precisely, fix the price. If you cannot yet, pay to find out first, and fix the price after.