14 October 20258 min read
A fixed price is the most reassuring number in procurement. It fits on one line, it survives a board slide, and it appears to move the risk of overrun onto the provider. That is why finance likes it, why it is often requested before anyone has read the scope, and why a large share of unhappy outsourcing engagements were fixed price on the day they were signed.
The reassurance is real but it is narrow. A fixed price transfers exactly one risk: the risk that the agreed work takes more effort than the provider estimated. It transfers nothing about whether the agreed work is the work you actually need. Everything you did not scope stays yours, and it stays yours under worse conditions than before, because now every discovery has to be negotiated rather than simply done.
A fixed price does not remove uncertainty from a project. It decides in advance who pays for it, and it decides that before anyone knows how much there is.
What a fixed price is actually pricing
A provider quoting a fixed price is doing three things at once. They are estimating the work as described. They are adding a contingency for the parts of the description they do not believe. And they are pricing the cost of arguing with you later, because they have done this before and they know that some of the scope will move.
None of that is dishonest. It is the only rational way to quote a fixed number against an incomplete description. But it has two consequences a buyer should understand before signing. The first is that you pay the contingency whether or not you need it, so a fixed price on well-understood work is usually the more expensive option. The second is that the provider now has a financial interest in the narrowest possible reading of every sentence in the scope, and you have one in the broadest. That opposition is built into the instrument, not into the people.
The scope questions
Start here, because if the scope is not tight enough to price, the rest of the contract is decoration. Ask the provider these in a call, not by email, and listen for hesitation rather than for the answer itself.
- Which parts of this scope are you least confident about, and what would make you more confident?
- What have you assumed that is not written down anywhere in the statement of work?
- Which third-party systems does this depend on, and what happens if one of them behaves differently than the documentation says?
- What are you expecting from us, by when, for this timeline to hold?
- If we asked you to quote this as time and materials instead, would the number be higher or lower, and why?
That last question is the useful one. A provider who says the time and materials number would be meaningfully lower is telling you honestly that they have priced uncertainty into the fixed number, and inviting you to decide whether you want to buy that insurance. A provider who says the numbers would be identical has either not thought about it or is not being straight with you.
The dependency questions
Most fixed-price overruns are not caused by the provider working slowly. They are caused by something the buyer owed and did not deliver on time: access to a staging environment, a decision from a stakeholder who was on holiday, sample data from a system the data team controls, sign-off on a design that went to a committee.
A fixed price with no buyer obligations written into it is a trap for both sides. The provider absorbs the delay until they cannot, and then the conversation turns into a dispute about whose fault the calendar is. Write your own obligations into the contract with dates attached, and accept that missing them has a cost. It feels like negotiating against yourself. It is the single clause that most reliably keeps a fixed-price engagement calm.
The change questions
Every fixed-price contract has a change request process, and almost nobody reads it before signing. Read it. The specific things to look for are how quickly a change request has to be answered, whether a change can be rejected outright or only priced, whether small changes below some threshold are absorbed, and whether the timeline moves automatically when scope is added.
Then ask the question behind the process: how many change requests does the provider expect on a project like this? A provider who says none is not describing any project that has ever happened. A provider who says they typically see a handful and here is how they usually handle them is describing reality and has a process for it.
The acceptance questions
A fixed price ends with someone deciding the work is done. If that decision is not defined in advance, it becomes the most expensive conversation in the project. The definition of done has to be checkable by a person who was not in the room when the scope was written, and it has to be checkable without goodwill, because by the time you need it goodwill may be gone.
- What exactly is the deliverable: running software in your environment, a repository, a deployment, or a demonstration?
- Who signs it off on your side, and what happens if that person is unavailable?
- How long do you have to test before acceptance is assumed?
- What counts as a defect covered by the price, and what counts as a new requirement?
- Is there a warranty period after acceptance, and what does it cover?
The defect boundary is where fixed-price engagements most often turn sour. Agree the rule in plain language: a defect is behaviour that contradicts something written in the scope, and anything else is a change. It is a blunt rule and it will occasionally be unfair to one side. It is still better than the alternative, which is deciding case by case while both sides are already annoyed.
The questions nobody asks about the people
A fixed price says nothing about who does the work, and that silence is deliberate on the provider's side. If the price is fixed, staffing is their lever: a project under pressure gets the cheaper engineer, and a project that is going well loses its best person to a project that is not.
You do not need to control staffing, and you should not try. But you should ask who is assigned, whether they are dedicated or shared across accounts, how much notice you get before a change, and whether you meet a replacement before they start. In staff augmentation these questions are natural because you are buying named people. In managed delivery they feel intrusive, and they are the ones worth asking anyway.
When fixed price is genuinely the right instrument
None of this makes fixed price wrong. It makes it specific. It fits work where the requirements are already settled, the acceptance criteria are testable, the dependencies are inside the provider's control, and neither side expects to learn anything during delivery that changes what should be built.
That describes more work than cynics admit. A migration with a known source and target. An integration against a documented and stable API. A rebuild of a screen whose behaviour is fully observable in the existing product. A defined audit, a defined test suite, a defined accessibility remediation. For these, a fixed price is a fair trade: you pay a contingency you probably do not need, and in exchange you stop having to manage effort.
It fits badly where the point of the work is to find out what the work is. Discovery, product design, anything described with the word roughly, anything where a stakeholder has not yet seen a version of it. For those, a time and materials arrangement with a capped budget and a checkpoint every two weeks costs less and produces a better result, because the checkpoints let you steer instead of forcing you to have been right at the start.
What to do before you sign
Take the statement of work and mark every sentence that could be read two ways. If there are more than a handful, the project is not ready to be priced and you are about to buy an argument. Send the marked copy to the provider and ask them to write the reading they intend. That exchange costs a few days and is the cheapest risk reduction available to you at any point in the engagement.
And decide, before the negotiation, what you would actually do if the provider turned out to be wrong about the estimate. If the honest answer is that you would want the work finished properly regardless, a fixed price is not protecting you, it is only deciding who has to raise the subject first. Better to know that going in.