What a fixed-price quote actually covers

Why buyers want a fixed price

A fixed price transfers risk. You know the number, you can get it approved, and if the work takes longer than expected that is the supplier's problem. It is a reasonable thing to want, and any vendor who refuses to quote fixed for well-defined work is telling you something about their confidence.

But the number only means anything alongside the document it was calculated from. A fixed price against a vague brief is not certainty. It is a supplier's guess with a margin bolted on, and it will be defended later by arguing about what was implied.

What is inside a fixed price

A proper fixed-price proposal contains a scope statement listing what will be built, in enough detail that two different engineers would build roughly the same thing. It contains assumptions: the systems you will give access to, the data you will provide, the decisions you will make and by when. It contains exclusions, which are as important as the scope.

It should also contain a phase plan. Fixed price does not have to mean one payment at the end of six months. We break work into phases with their own deliverables, so you are never more than one phase exposed and you can stop at a phase boundary with something usable in hand.

And it contains contingency, whether or not the vendor says so. Any honest fixed price includes a buffer for the things nobody can foresee. If a quote looks suspiciously low against others, the difference is usually that buffer, and you will meet it later as a change request.

What sits outside it, almost always

Changes of mind. Not because vendors are inflexible, but because a fixed price is arithmetic performed on a specific scope. When the scope moves, the arithmetic has to be redone. A good vendor prices the change quickly, tells you the impact on the timeline, and lets you decide.

Third-party surprises. If an integration turns out to need a licence tier you do not have, or a vendor's API cannot do what its documentation implies, that is usually outside the price. Look for that in the assumptions.

Delays on your side. If sign-off takes three weeks instead of three days, the project stretches. Most fixed-price agreements are silent on this, which is how a schedule quietly becomes nobody's fault. Ask how your own responsiveness is handled.

Post-launch work. Fixing defects against the agreed scope should be included, usually for a stated warranty period. New features, environment changes and support are separate.

When a fixed price is the wrong instrument

If the requirements are genuinely unclear, insisting on fixed price makes the project worse. The supplier prices the risk, so you pay more; and every conversation afterwards becomes a negotiation about scope rather than a discussion about what would be best to build.

The better pattern for unclear work is a small fixed-price discovery phase, priced in days rather than months, which produces the specification that a larger fixed price can then be quoted against. You keep the document either way, so it is useful even if you take it to another vendor.

Ongoing work with shifting priorities suits a retainer or a dedicated team arrangement. Forcing it into fixed scope generates a change request every fortnight and irritates everyone.

Five questions to ask before you sign

What specifically is excluded? A vendor who cannot answer this quickly has not thought about it.

What happens if we change our mind in week six? You want a stated process, not a shrug or a promise to be reasonable.

What are you assuming about our involvement? Look for named responsibilities and turnaround expectations.

How is the work phased, and what do we own at the end of each phase? You should never be one payment away from having nothing.

What is the warranty on defects, and how is a defect distinguished from a change? This is the argument that most often sours the end of a project, and it is trivially avoidable by agreeing the definition up front.