Fixed fees for bespoke software, and why most companies will not offer them

The scoping discipline that makes a fixed price possible, and the documents that have to exist before it can be honestly quoted.

“How much will it cost?” is a question that deserves a number, and most bespoke software companies answer it with a rate. There is a reason for that which has nothing to do with dishonesty, and I want to set it out properly, because it explains both why we quote a fixed fee and why most suppliers will not.

What an hourly rate is actually pricing

An hourly or daily rate prices the supplier’s uncertainty, and it transfers the cost of that uncertainty to the client. Every question the brief did not answer becomes billable time when it comes up later. Every misunderstanding is paid for twice, once to build the wrong thing and once to build the right one. Under a day rate the supplier has no financial reason to resolve vagueness early, because vagueness is where the hours come from.

This is a matter of incentive rather than of character. Good developers on day rates do good work. But under that arrangement the risk of a vague brief sits entirely with the client, and most clients do not discover this until the fourth month’s invoice arrives.

The documents that have to exist before a price can be fixed

A fixed price is only honest when it follows a scoping discipline that most suppliers skip, because the discipline costs time before any money is earned. There are four documents, and they are produced in this order.

The first is a set of sourced requirements. Each requirement is traced to a named person and a specific conversation: who needs it, what they do today, and what the system must do instead. A requirement that cannot be traced to a source is a guess, and guesses are where overruns come from.

The second is a set of options with costs. There are usually two or three ways to meet the requirements, and each is set out with a price and a statement of what it gives up. One of the options is often not to build at all, because an existing product or a change to the process would meet the need well enough. The client chooses with the numbers in front of them.

The third is a clickable prototype, approved before any production code is written. A prototype in this sense is a working model of every screen that opens in a browser and can be clicked through, but is not yet connected to anything. The client uses it in their own office with their own people. A change at this stage costs hours; the same change after production code has been written costs weeks. Approval of the prototype is the point at which the shape of the system stops moving.

The fourth is a locked specification: what will be built, what will not, and the criteria by which the client will accept it, signed by both parties. This is the document to which the price is attached, and it is the reason the price can be fixed.

A fixed price quoted before these four documents exist is a guess presented as a commitment, and someone will pay for the difference. We do not quote one until the scoping is complete. The scoping is itself a defined piece of work with its own fixed price, so that a client is never asked to commit to a build before knowing what the build is.

What a scope change is, and what it is not

A scope change is a document that both parties sign. It states the change, its effect on the price, and its effect on the delivery date. To illustrate: if the report that was specified to show a week’s jobs is now wanted to show a month’s, that is a scope change, and the document says so, says what it adds to the price and to the date, and is signed by both sides before the work is done. A telephone call is not a scope change, nor is a message, nor is a remark in a meeting. Any request that has not been written up is one of two things: it is either inside the specification, in which case it is already paid for and will be done, or it is outside the specification, in which case nothing has been agreed until the document exists.

This protects both sides. The client is never surprised by an invoice, and the supplier is never asked to absorb work that was not in the scope. The phrase to be careful with is “small tweak”. A small tweak is either inside the specification or it is a document; there is no third category.

Staged payment, and why the final stage falls on transfer

A fixed fee is paid in three stages, against milestones that both parties witness: on commencement, on delivery of the working system for acceptance, and on transfer. Nothing is due for work that has not been shown.

The final stage falls on the transfer of the intellectual property, which is the legal ownership of the code. Until that payment the code is held by the company, on the company’s own infrastructure. After it the client owns the source, the documentation and the right to do anything with them, including taking them elsewhere. The last payment buys the thing the client can take anywhere, which is the right point for it to be made.

Why most suppliers will not offer this

There are three reasons, and all three are rational from the supplier’s point of view.

The scoping discipline costs time before it earns anything. Sourced requirements, costed options and a prototype take weeks to produce. A supplier billing by the hour is being paid during those weeks; a supplier scoping for a fixed fee is investing in them.

A fixed fee exposes the total price early. The client sees the whole figure before committing to anything. A day rate reveals the total only when it is too late to walk away.

Hourly billing is safer for the supplier. Every risk of vagueness, change and misunderstanding is passed to the client. A fixed fee keeps those risks with the party that can control them, which is the supplier, and most suppliers would rather not carry them.

That third point is, to my mind, the whole argument. The party that controls the work should carry the risk of the work. That is what a fixed fee means, and it is why the scoping has to be done properly before the fee is quoted.

What to ask a supplier

Will you fix the price? What has to exist before you will? What counts as a scope change, and what does one look like? What is due before you have shown me anything? A supplier who works this way will have the documents to hand and will be pleased to be asked. A supplier who does not will usually explain that your project is different. Every project is different; that is precisely what the specification is for.

Written by the people who do the work at EGM Software. All Insights · Write to the company