How to define a project so the price is not argued about afterwards

A dispute about price starts long before the final invoice. It starts with the sentence "that is obvious".

Imagine a brief that says "order records". The client imagines an export to the accounting system as part of it. The supplier does not. Nobody lied; nobody simply wrote a single line about it. In the end, one side takes the export for granted and the other sees it as extra work.

Most disputes like this can be avoided. It is enough to agree on three things before you start: what is and is not in scope, how you will tell that it is done, and how changes are priced.

Scope is also a list of what is not in the price

A typical offer says what will be built. It is just as important to write down what will not be built. This is the strongest tool in this whole article, because it turns gaps in the brief into open questions.

The list of excluded items typically includes:

• migrating data from the existing system,
• changes to surrounding systems,
• performance tuning beyond an agreed limit,
• further language versions,
• connections to services that are not in the brief,
• user training,
• support and changes after acceptance.

That does not mean you do not want these things. Maybe you do, and they will be in the price. The point is that someone decides about each of them consciously.

Then agree a simple rule: what is not in scope is a change and is priced in advance. That removes most of the arguments about what should have been obvious.

Next to the scope, write down the assumptions too. For example "the client supplies the data" or "the accounting software can export to a file". When an assumption turns out to be false, that is a change, not an argument about who should have foreseen it.

Acceptance agreed in advance

Done is not an opinion. It is a ticked-off list. For that to hold, every item must be verifiable and agreed before work starts.

You can see the difference in these illustrative examples:

Writing acceptance has a useful side effect: you immediately see where the brief has holes. If nobody can say how to tell that the report is correct, it is not specified well enough. Now is the cheapest place to find that out.

Split a larger project into smaller parts, each with its own acceptance. A dispute about one part is easier to settle than a dispute about the whole work. Also agree a deadline for comments and a rule that a rejection must point to a specific unmet criterion. Whether silence should count as acceptance is something for a lawyer to assess.

Changes are priced before they are made

A change to the brief is not a failure. During development it often turns out that you want something different. The problem is a change whose price you only learn from the invoice.

The process can be short:

1. The change is written down, a few sentences in an email are enough.
2. The supplier states the price and the effect on the deadline.
3. You approve it or reject it.
4. Only then does work on it begin.

This applies to small changes too, because those are exactly the ones that add up unnoticed. And it works both ways: the supplier does nothing unapproved, and the client does not expect "just this one more thing" to fit in the price.

The same goes for deadlines. If the supplier waits three weeks for access or for your comments, the deadline moves by three weeks. It is fair to write that down in advance.

Why a fixed price on a system nobody has opened is a bet

A fixed price is a good thing for the client. The risk of a bad estimate is carried by the supplier, not by you. But that holds only when the scope is truly bounded.

A brief can be read in one afternoon. An old system that a new part is to connect to cannot. It hides undocumented connections, missing tests and data that does not look the way it should. Whoever gives a fixed price without opening the system is guessing. There are three possible outcomes:

• They guess high. You overpay for a reserve against risks that may never happen.
• They guess low. Then they start cutting corners on quality, or they report every small thing as a change.
• They get it right. That is good, but it is luck.

The honest order is access to the code, then an estimate and only then a price. What you can do about it:

• Give the supplier access to the code before signing, perhaps under a confidentiality agreement.
• Order a short paid audit first. It costs money, but it is cheaper than a bad project.
• If access cannot be given, the supplier should either count a full reserve or not promise a fixed price at all.
• Ask what the price is made of and what reserve it contains. Whoever has seen the system will answer specifically.

If someone gives a fixed price after a short phone call, that is not a sign of confidence. It is a question of who ends up paying for the bet.

Before you sign

This is how we work on custom software and on outsourcing, where we build a defined part of your system to your specification.