A fixed price on work that nobody fully understands yet does not remove risk. It moves the risk to the supplier, prices it, and then creates an incentive for both sides to fight about scope for the rest of the project. That is why almost every fixed-price software project ends in the same argument, and why the argument feels dishonest even when neither party is being dishonest.
This is uncomfortable for us to publish, because clients ask for fixed prices and suppliers who refuse them lose work. But the mechanism is worth understanding before you sign, because once you have signed, the incentives take over and neither goodwill nor a good relationship will fully override them.
The case for fixed prices, put properly
It would be easy to argue against a weak version, so here is the strong one. A fixed price gives you a number you can take to whoever approves spending. It caps your exposure. It puts the risk of a bad estimate on the people who made it, which is where it arguably belongs. And it protects you from the genuine failure mode at the other end, where an hourly arrangement drifts for months with no particular urgency and no obvious moment to stop.
All of that is real. Anyone who dismisses the appeal of a fixed price has not sat in front of a board asking how much this will cost. The problem is not that people want certainty. It is that a fixed price on unknown work delivers the appearance of certainty and charges you for it twice.
What a fixed-price software quote actually buys
When a supplier fixes a price on work with genuine unknowns, they are doing one of three things. They have understood the job well enough to price it, which is entirely possible and is what you hope for. Or they have added a contingency large enough to survive being wrong. Or they have priced it keenly, intending to recover the difference through change requests.
You cannot tell which from the number. All three look like a confident quote in a document. That is the whole difficulty, and it is why the cheapest fixed price is so often the most expensive project.
Where the padding goes
Take the honest supplier who has added contingency, because that is the good case. They have looked at the uncertain parts and added, say, thirty or forty per cent to cover being wrong.
If the project goes well, you pay that contingency anyway. It is in the price. You do not get it back, and you will never know it was there, because nobody itemises the money they set aside for problems that did not happen. So on a well-run project, a fixed price means you paid an insurance premium against a risk that did not materialise. That may be a trade you would happily make. You should just know you are making it.
Where the corners get cut
Now the case where the estimate was wrong and the supplier is over budget. They are contractually obliged to finish. Every additional hour comes out of their margin, and they have staff to pay.
Nobody makes a decision to ship something worse. The pressure is quieter than that and it lands in predictable places: the tests that would have caught next year's bug, the error handling for cases that seem unlikely, the accessibility work, the documentation, the tidying that makes the next change cheap. None of it is visible at handover. All of it is visible eighteen months later when a small change costs more than it should and nobody can explain why.
This is the part clients never see, because the failure is deferred. The project delivered on time and on budget. The cost arrived later, as maintenance, and by then it looks like bad luck.
The change-request trap
Then there is the third case, and the reason for the phrase that everyone in this industry recognises: it was not in scope.
Once a price is fixed against a specification, the specification becomes the contract, and anything not in it is chargeable. That sounds reasonable until you notice what it does to the conversation. You become reluctant to mention improvements because everything sounds like a bill. The supplier becomes reluctant to suggest better ideas because they would be absorbing the cost. Both of you end up defending a document written when you knew least about the problem.
The perverse result is that the arrangement designed to protect you actively discourages the thing that makes software good, which is changing your mind when you learn something.
The model that protects both sides
There is a middle, and it is what we use for anything with real unknowns. It keeps the budget control that makes fixed prices attractive without pretending the unknowns are known.
- Fix a small piece first. A paid discovery: a fortnight or so, a fixed and modest price, producing a real plan, the technical approach and a properly informed estimate. You end up owning that work whether or not you continue with the same supplier, which is the point.
- Fix the price on what is genuinely known. Plenty of a project is well understood, and it should be fixed. Nobody needs an open-ended arrangement for building a settled set of screens.
- Cap the uncertain part rather than fixing it. A ceiling you will not exceed without a conversation, billed on what is used. You get exposure control and the supplier does not need to pad.
- Work in short blocks with a real stop. Two weeks, something working at the end, and a genuine option to stop. That is the strongest protection any buyer has, and it is stronger than a contract clause.
- Agree how changes are handled before you need to. Not a price list. A named person on each side who decides, and a default that small trades within a block are handled by swapping something out rather than by raising an invoice.
Point four is the one to insist on. A supplier who is comfortable with you being able to stop after two weeks is telling you something about their confidence that no reference call can.
What to ask instead
- What is this estimate most likely to be wrong about? A good answer names the uncertain part before you have paid. A confident number with no caveats is a bet you are underwriting.
- How much contingency is in this, and what happens if it is not needed? Rarely asked, and the reaction is informative on its own.
- What would you cut first if you were running over? Everyone has an answer. You want to hear it now, not discover it later.
- Can we do a paid discovery first? If the answer is that it is not necessary on a project with real unknowns, ask how they know.
- What happens if we want to stop after four weeks? The response tells you whether you are buying a partnership or being locked into one.
These belong in the first conversation, alongside the rest of the list in twenty questions to ask a development agency. And if you are earlier than that and simply want a sense of what things cost, how much does a website cost sets out ranges by type of project.
Not for you if
What to do differently: stop asking what it will cost as the opening question, and start asking what we do not know yet and what it would take to find out. The suppliers worth hiring will be relieved you asked. The ones who were going to pad or cut will be visibly less comfortable, and that is the most useful information you can get before signing anything.