Most development projects are billed by the hour. That is easy for the supplier: the client pays for the time it takes, however long that is. But it also means all the risk sits with the client. If the job turns out harder than expected, it is the client's bill that grows.
We do it the other way round, and it is not because we are nice. It is because it forces us to do something we ought to do anyway.
What a fixed price demands of us
We cannot put a price on something we do not understand. So before we give a number, we have to have been through the job: which systems are involved, what it has to do, where the unknowns are. That work costs us time, and we do not pass that bill on.
That is the price of the model, and it is worth paying. Clients who have been given a fixed price know what they are saying yes to. And we know what we have promised.
What happens when the job changes
It always does. Someone thinks of something clever along the way, or a system turns out not to do what everyone assumed. Then we talk about it: is this within scope, or is it a new job with a new price? What matters is that it is a conversation, not a surprise on the invoice.
Within scope
Small adjustments and better solutions to what was agreed. Those we absorb.
New job, new price
If it was not in scope, we put a price on it and you decide.
Swap rather than add
Often something new can come in by letting something else go. That costs nothing.
Always in writing
Changes are written down the same day. Nobody should have to recall a conversation from three weeks ago.
Where the model does not fit
Maintenance and ongoing development suit a fixed price poorly, because nobody knows what will come up. There we work with service plans: a fixed number of hours per month, which you decide how to spend. Still predictable, just in a different way.