A fixed price implies a known scope. Most real projects include at least one piece nobody can honestly scope in advance — usually a third-party integration whose documentation does not match its actual behaviour, discovered only once someone is inside it.
Naming the unknown out loud
Rather than absorbing that risk into a padded overall number, or refusing to quote at all, we split the estimate into fixed and time-boxed parts and say so in the proposal. The client sees exactly which piece carries the uncertainty and why.
How the split actually works
- Fixed price for everything we have built something comparable to before, or where a competitor's public documentation and our own testing give us confidence.
- Time-boxed spike for the unknown piece — a capped, paid block of time to actually integrate against the real API or system and find out what it does.
- A firm re-quote once the spike is done, based on what was actually found, before any further commitment.
Why padding the fixed price is worse for everyone
Padding a single number to cover an unknown either overcharges the client when the integration turns out to be straightforward, or undercharges the studio when it turns out to be a mess — and the studio absorbing an unbounded loss on a fixed price is exactly the incentive that produces corner-cutting later in the project. Naming the risk explicitly removes that incentive entirely.
A fixed price on an unknown is not confidence. It is a guess wearing a confident number.
What clients actually think of this
Most clients prefer it once it is explained, because it means the fixed portions of the quote are genuinely fixed rather than quietly inflated to cover a risk they were never told about. The ones who insist on a single number for everything are, in our experience, the ones most likely to dispute the invoice later.
The spike itself has to be real work
A time-boxed spike is not a proof of concept for marketing purposes — it produces the actual integration code, tested against the actual third-party system, that ships if the project proceeds. Throwaway spikes teach you less than you think, because the throwaway version skips exactly the parts that turn out to be hard.
Where this has saved a relationship
On one project the spike found that a payment provider's sandbox environment behaved differently enough from production that the original scope would have been unworkable. Finding that out for a capped fee, with the client's agreement already in place about what would happen next, was a far better conversation than finding it out mid-build against a fixed price neither side could adjust.