A fixed-price software project works by agreeing exactly what will be built, and for how much, before the build starts. The price is a promise made against a written specification. That is what makes it fixed, and it is also why changes have to be handled deliberately. If you change what is being built, you change the thing the price was promised against.
Good fixed-price projects do not pretend change never happens. They have a clear, fair way to deal with it. This is how the model actually works, and how to keep the change-request conversation from turning into a fight.
Key takeaways
- A fixed price is a promise made against a written specification. The clearer the spec, the more reliable the price.
- The work runs in a set order: scope and specify first, agree the price, then build to the agreed spec.
- A change request is any work that was not in the agreed specification. Handling changes is normal, not a sign something went wrong.
- Good suppliers price changes transparently as they come up, so you decide each one on its merits, rather than absorbing them silently or saving up a bill for the end.
- Expect to want changes once you see the software taking shape. Budget some contingency for them instead of assuming the first spec is final.
- Fixed pricing suits projects small enough to estimate accurately. On a large build the price is either a gamble the supplier is taking or padding you are paying for, so fixing the price of each phase in turn works better.
What a fixed price actually fixes
A fixed price fixes the cost of building an agreed specification. The specification is the backbone of the whole arrangement: it says what is in, what is out, and what "finished" looks like. When it is clear, the supplier can commit to a firm price and carry the risk if the work runs long. When it is vague, any price is a guess dressed up as a promise.
What a fixed price does not fix is your understanding of what you want. That keeps developing, especially once you can see and use the software. This is not a flaw in you or the process. It is the single most common reason for change requests in fixed-price projects. This is worth planning for rather than being surprised by.
How a fixed-price project runs, step by step
Most fixed-price builds follow the same shape:
- Scope and specify. Before any code, the work is pinned down: what it does, who uses it, what is in and out, often with wireframes so you can see it. Our scoping step produces a detailed specification, interactive wireframes, and a fixed-price quote you can take to any supplier, not just us.
- Agree the price and the phases. The build is usually broken into phases with their own deliverables, so payment and progress track each other.
- Build to the spec. The team builds what was agreed, ideally showing you working software at each phase rather than at the very end.
- Accept against the spec. "Done" is measured against the specification you signed off, not against a moving target.
The up-front work in step one is what earns you the firm number. It is also where you decide most of what you are getting, so it is worth your attention. For how the number itself is arrived at, see our guide to what bespoke software costs in the UK.
What counts as a change request
A change request is any work that was not in the agreed specification. It helps to separate two things that often get confused:
- A clarification is something the spec already implied, just spelled out in more detail. This should not cost extra.
- A change is something new or different: a feature nobody scoped, a rule that has altered, an extra integration, a redesign of a screen you already approved. This is new work, and new work has a cost.
The specification is what lets both sides tell these apart honestly. Without one, every disagreement becomes your word against theirs.
How change requests get handled, and priced
The mechanism is simple and it should be agreed before the build starts. When a change comes up, the supplier estimates its impact on cost and timeline, and you decide whether it is worth it before any work goes ahead. The extra work is usually priced at a day rate, because a change is, by definition, the part nobody could fix a price to in advance.
The point of this is that you stay in control. Nothing gets added silently, and no surprise bill turns up at the end. A supplier who absorbs every change for free is not being generous. They are either padding the original price to cover it, or cutting a corner elsewhere to protect their margin. Transparent change control is better for you than either.
How to avoid the change-request fight
The bad version of this, where change requests become a running battle, usually starts before the build does. A supplier who under-scoped to win the work has to recover the money somewhere, and change requests are where it surfaces. That is how a cheap quote actually becomes an expensive project. Your protection is to agree the change process before you sign, and to read the specification you are agreeing it against.
Two more habits help. Keep a contingency in your budget for the changes you will want once the software is real, rather than assuming the first spec is final. And choose a supplier who raises changes early, when you can still decide, over one who quietly banks them. That behaviour is about the relationship, not the contract, and it is worth more than any clause.
When fixed price is not the right shape
If you genuinely cannot specify the work yet, because the idea is still forming or you expect big pivots, a fixed price forces a false certainty and turns every step into a change request. That is miserable for everyone. When you are in that position, a short discovery phase or a day-rate start is the honest choice, used to reach the clarity that makes a fixed price possible later.
Size is the other limit, and it is less talked about. Fixed pricing works best on projects small enough to estimate with real accuracy. Past that point the estimate carries so much risk that a supplier has two choices: absorb it and hope, or pad the price until it is safe. Either way you stop getting the thing you were promised, which was a fair price for known work. On a large build, phasing the work and fixing the price of each phase in turn will usually serve you better than one big number.
What to do next
Before you sign a fixed price, ask two questions. Is the specification detailed enough that I could hand it to any supplier and get the same thing built? And do I know exactly how a change will be raised, priced and agreed once we start? If both answers are yes, a fixed price will serve you well.
If you are not sure whether your project is specified well enough to be priced that way, send us what you have. We will tell you what is missing, and whether a fixed price is the right shape for this work in the first place.
FAQs
Which is better, a fixed price or a day rate?
They protect different things. A fixed price protects your budget and puts the risk of overrun on the supplier. A day rate protects your ability to change direction, and puts that risk on you. Neither is the more honest model, and a supplier who only ever offers one of them is telling you something. We compare the two in fixed price or day rate.
What should a specification actually contain?
Enough that someone who has never met you could build the right thing from it. In practice that means what each screen does, who is allowed to do what, the rules the software has to follow, what it connects to, and what should happen when something goes wrong. Wireframes help, because a picture settles arguments that paragraphs do not. If you cannot tell from the document whether a feature is in or out, it is not finished.
Can an Agile project be fixed price?
Yes, but not in the way people usually mean. You cannot fix a price against a backlog that is free to change, because the price was promised against something specific. What works is fixing the price of a defined phase, delivering it, then scoping and pricing the next phase with what you learned. You keep the freedom to change direction between phases rather than during them.