What a fixed-price software quote should say before you sign it

The cheapest quote is rarely the cheapest project. The difference doesn’t come from the number on the page; it comes from what the page leaves out. When the scope is vague, every change becomes a negotiation about money. When the warranty isn’t written down, every bug after launch becomes new paid work.

Before you sign, check that the quote in your hand covers these nine things.

1 The cheaper quote One line of scope, so each change becomes a new bill during the build.
2 After a 30-day warranty Bugs found after launch turn into new paid work.
3 The quote that writes it all down Costs more at signing. Changes are priced before they're built, and bugs in scope are fixed under the warranty.
What the page left out The difference you pay by the end.

Fig. 1 Illustrative. The quote that looks cheapest at signing can cost the most by the end, through what it didn't write down.

1. Scope as features, not a system name

“A complete HR system” isn’t a scope. A good scope says, item by item, what the system does, who uses it, and the rules that matter: “Staff submit leave requests, managers approve them in LINE, and the leave balance updates by itself.” If you can’t picture someone using it, you will argue about it at sign-off.

2. What isn’t included

A good quote also says what it leaves out: migrating data from the old system, server costs, training. Whatever isn’t written down is what you find out about at the end.

3. What is needed from you, and by when

Projects stall on the client’s side as often as on the vendor’s: an approval from IT, a sample data file, real users to try the system. Written down at the start, both sides know where a delay came from.

4. Milestones tied to real demos

Paying in milestones protects both sides, but each milestone should be tied to something you have seen and tried, not to a date on a calendar. And no more than half should be paid before you see any work.

1 Paid as you see it For example 40% at signing, 40% after the first demo, 20% after the final one.
2 Paid by the calendar Most of the money falls due before any demo, on dates rather than results.
More than half before any work If a payment plan enters this area, ask why.

Fig. 2 What you've paid, against what you've seen. A good payment plan never gets more than half ahead of the work.

5. How changes are handled

Requirements change; that’s normal. What you need to know is how a change is priced. The best answer: it is priced and agreed before it is built, every time, not discovered on the invoice.

6. The warranty: how long, and what it covers

A system that has just gone live always meets bugs that testing never found. Check how many months the warranty runs and whether it covers bugs in everything in the scope. Thirty days on a system people use every day is barely a warranty.

7. Who owns the code and the accounts

The source code should live in your organisation’s repository from the first day, and the accounts (domain, cloud, app stores) should be opened in your name. If the quote says “source code delivered on request”, ask why straight away.

8. What you receive at handover

Besides a working system: a system map, how to deploy, how to restore a backup, and user guides. These documents are what let you change vendors, if one day you need to.

9. Support after launch

Ask what support costs now, not after launch, when you have the least leverage. A good quote says what support covers, how fast it responds and what it costs.

Five signs to ask more questions

The scope is one line long.
More than half is due before you see any work.
No one is named as the person who will build it.
The price arrived within a day, without anyone asking you anything.
Testing isn’t mentioned once.

Why we don’t give a fixed price on day one

1 A price on day one Nobody can list the work yet, so the price carries a large buffer or gets topped up later.
2 Blueprint Two to three weeks writing down every item in this checklist.
3 One fixed price Quoted from that written scope. The documents are yours either way.

Fig. 3 The range a price could land in narrows as the work gets written down. A fixed price belongs at the narrow end.

Because nobody knows yet what has to be built. A price given that fast either carries a very large buffer or gets topped up later. So most of our projects start with a Blueprint: two to three weeks to write down everything above, then one fixed price. When the need is clear enough to list every feature on the first call, we quote straight away (how every step is charged). If you don’t go on to build with us, the documents are still yours, and any other vendor can quote from them. See a sample quote and the other documents.