For our first three years we gave fixed-price estimates per project. We were good at it — within ten percent on average — and our clients trusted the number. We still failed half of those projects on time, scope, or both. Because the number was wrong.
A software estimate has the same epistemic problem as a weather forecast for next month: the system is too complex to predict precisely, and giving a precise answer creates a false impression of confidence. We used to compensate by padding generously. The padding ate margins on simple projects and was eaten by surprises on hard ones.
The shift to sprint-based pricing solved this. A two-week sprint costs what a two-week sprint costs. Inside that sprint we make the trade-offs the brief allows. If the work overruns, the question is not "should I open the contract" but "do we need a second sprint." It is a calmer conversation.
Clients adapt to this faster than we expected. The first half of the first call is sometimes uncomfortable — they want a single number, we want to talk about scope. By the end of that call, they almost always prefer the new model. They have been burned too often by the old one.
There is a remaining problem: how do clients compare us to a competitor giving a single fixed number? The answer is they don't, really. They compare us on the brief we wrote, on the client list, on the conversation. The number is the last thing they decide on, not the first.