Somebody has to be wrong about how long this takes. Software estimates are wrong routinely, in both directions, and no contract structure changes that.
What a contract structure decides is who pays when it happens. That is the entire debate, and it is usually conducted as though it were about flexibility.
What each model actually says
Fixed price says: the supplier estimates, the supplier is wrong, the supplier absorbs it. You know the number before you commit.
Time and materials says: the supplier estimates, the supplier is wrong, the client absorbs it. You find out the number at the end.
Stated that plainly, fixed price sounds obviously better for the buyer, and suppliers who prefer T&M sound like they are avoiding accountability. That is too simple, and the reason is worth understanding.
Why fixed price has a price
A supplier quoting fixed has to price the risk. If a job is six weeks of work with a real possibility of ten, the quote is not six weeks of cost. It is somewhere between, weighted by how confident they are.
So you pay a premium for certainty. That is a completely reasonable trade and most buyers should take it, because certainty is worth more to a company with one budget than the premium costs.
It also creates an incentive worth naming: a supplier on a fixed price wants the scope to stay fixed. That is good when it means they push back on drift, and bad when it means they argue that something obviously necessary was not in the document. Which is why the quality of the scope matters more under fixed price than under any other arrangement.
Why time and materials is sometimes the honest answer
There are jobs that genuinely cannot be estimated.
Integrating with a twenty year old system nobody has documentation for. Debugging a problem that has not been reproduced yet. Ongoing changes to a system that already exists, where each individual item is two hours and the list has no end.
Quoting a fixed price for any of those means quoting a guess with a large safety margin, which you then pay whether or not the margin was needed. T&M with a cap and weekly reporting is usually cheaper and more honest.
The tell for when T&M is being misused: it is a new build, with a clear scope, and the supplier still will not name a number. That is the estimate risk being handed to you quietly.
What we do and why
We quote fixed for new builds, and the number does not move mid-project even when we have estimated badly. That is not generosity, it is where the risk belongs: we are the ones who can judge how long the work takes, so we should be the ones exposed if we judge it wrong. You cannot evaluate our estimate, so you should not be carrying it.
Changes you ask for later are quoted separately, also fixed, also before they are built. That makes changing your mind a priced decision rather than an argument, which is better for both sides than the alternative where every request becomes a negotiation about whether it was implied.
For maintenance and small modifications on an existing system, hourly is more honest and we say so. Pretending to fix-price a stream of two hour tasks means either padding every one of them or arguing about each.
The questions that actually protect you
Whichever model, these matter more than the model:
What exactly is in scope, written down, before anybody starts? Not a feature list. A description of what the system does, in the language of your business, that you could hand to a different supplier.
What happens when something turns out to be harder than expected? Ask it directly. The answer reveals more than the pricing model does.
How do I see progress? Weekly, running, in a browser, not a status report. A demo is a fact; a percentage is an opinion. This is the single best protection against either model going wrong, because it turns a six week bet into six one-week bets.
What are the payment stages tied to? Dates, or deliveries? Tie them to deliveries. A schedule tied to the calendar pays for time; a schedule tied to stages pays for progress, and the difference shows up precisely when the project is going badly.
The uncomfortable bit
A fixed price you cannot afford to be wrong about will make a supplier cut corners near the end. That risk is real and no clause removes it.
The mitigation is not contractual. It is the weekly demo, the fact that the code and the infrastructure are yours throughout rather than at the end, and that a supplier who cannot hold the work hostage has to finish well in order to be kept.
Which is the argument for asking about ownership before asking about price, even though almost everybody does it the other way round.