When we first published this article in 2020 it argued that fixed-price software projects were best avoided. We have changed our minds, and this version explains why, and what has to be true for a fixed price to work.
The short answer: fixed price is a sensible way to buy software when the deliverable is clear and both sides have agreed how uncertainty and change will be handled. It is a poor fit for an undefined project presented as a single guaranteed number.
Why fixed-price projects earned a bad name
The failures follow a pattern. A buyer describes what they want in a page or two. A supplier, keen to win the work, names a price. Neither side has examined the existing data, the systems to be connected or the dozens of small rules the business takes for granted. Work begins, the gaps appear, and one of four things happens:
- the supplier absorbs the overrun and the quality drops;
- the supplier asks for more money;
- every clarification is treated as a chargeable change;
- the project stalls with the budget spent and nothing usable delivered.
In each case the price was fixed and the scope was not. A fixed price attached to a vague scope is a guess, and somebody ends up paying for the difference.
What has changed
Two things have made fixed pricing more dependable than it was.
The first is that building software has become quicker. AI-assisted development has cut the time needed to write and test a given piece of functionality, so the cost of being somewhat wrong in an estimate is smaller than it used to be.
The second is that the uncertain parts of a project can now be investigated cheaply before the price is set. A working prototype built from a client’s own spreadsheet or screens, in days, exposes misunderstandings that would once have surfaced months into the build.
Neither removes the need to agree the scope. They make it realistic to do so before committing.
What to agree before you sign
A fixed-price agreement is worth having when it covers these seven things.
1. The deliverable
Who will use the system, which tasks it must support and what it must connect to. Describe outcomes: “a dispatcher can assign a job to an engineer and see it on the schedule”, not “a scheduling module”.
2. The unknowns, resolved
Anything that could change the amount of work should be looked at before the price is set: the quality of existing data, access to third-party systems, technical constraints in what is already there. A short paid discovery stage is the normal way to do this.
3. Acceptance checks
How you will decide the work is finished. Observable checks, named approvers and a process for resolving issues. Without these, “done” is a matter of opinion.
4. Assumptions and exclusions
Hosting, licences, data you will supply, content, training and ongoing maintenance. What is left out matters as much as what is included.
5. Change control
New requests will come up. Agree in advance that each one is assessed and quoted, and that you can add it, swap it for something of similar size or defer it. Nothing should be added to the bill without your agreement.
6. Like-for-like quotations
If you are comparing suppliers, compare what each quote covers. A low headline price means little if the suppliers are pricing different outcomes.
7. Whether fixed price fits at all
A defined build suits a fixed price. Exploratory work, open-ended improvement of an existing system and ongoing support do not, and are better arranged by the month.
Warning signs in a fixed-price quote
- It arrived quickly, with no questions asked.
- It is a single figure with a paragraph of description.
- There are no acceptance checks.
- Changes are not mentioned, or are charged at a rate you have not seen.
- It does not say who owns the code.
How we work
We offer fixed-price bespoke development for projects with an agreed scope, and a set of fixed-price packages for work we do often enough to price in advance. Where important questions are still open, we will say so and suggest how to answer them before either of us commits.
If a fixed-price project has already gone wrong, our project rescue page describes how we assess what has been built and what it would take to finish.