How to read a software quote

A quote for software is easy to read for the number and hard to read for everything else. The number is the part everyone looks at; the lines around it decide what the number buys, and the lines that are missing decide what it does not. Here is how we read one, our own included.

What a quote usually leaves out

Five things go unsaid more often than any other, and each of them turns into an invoice later:

• Support scope: "support included" without saying what counts as support, what counts as a billable extra, and how work is prioritised once the product is live.
• Change pricing: how a request after signature is priced, as a fixed quote, an hourly rate or a bundle. If it is not on the page, change is priced later, on the supplier's terms.
• Licence costs inside the monthly fee: third-party licences, hosting and services rolled into one line, so you cannot see what you are paying for or what you keep if you leave.
• Handover as a favour: nothing about what you receive at the end, so handover becomes a negotiation at the moment you have the least leverage.
• Hosting and accounts not in your name: the domain, the hosting and the third-party services registered to the supplier, which makes leaving a technical project rather than a decision.

None of these is dishonest on its own. A quote is a short document, and nobody writes down everything. The trouble is that silence reads as "included" to the buyer and as "extra" to the seller, and the difference only surfaces when it costs something.

A fixed price or a range

A single number looks safe. For work that has been done many times before it can be fair. For anything new it caps the project and usually costs more in the end, because the risk is priced in as padding you cannot see and every change has to pass through a re-estimate. We have written about why, and the short version is that a fixed price makes change expensive exactly when the freedom to change course is the point.

An estimate that respects you is a range with its assumptionsThe things the supplier took as given when sizing the work: what exists already, what you will provide, what is out of scope. If one turns out false, the number moves. written down: what the supplier thinks is simple, what they suspect is hard, and which unknowns will move the number. Either shape can be a fair quote. What matters is that you know which one you are holding, and what happens when reality differs from the assumptions.

What a good quote names

• Scope: what will be built, in words you understand, including what is explicitly not included.
• Acceptance: how you decide it is done, and who decides.
• Who does the work: named people, whether any part is subcontracted, and who your day-to-day contact is.
• What you receive: source code, documentation, credentials and accounts, in your name.
• What the monthly fee is made of: hosting, licences, support, and what each of those covers.
• How change and support are priced after launch, before you need either.

Our own general terms say that consultancy is an obligation of means, and that the concrete arrangements on scope, pricing, timelines, acceptance and intellectual property live in the project documents. That is deliberate: a general terms page cannot describe your project, so the quote and the scope document have to. The same goes for support. We scope it per system and agree it up front, and we work by priority rather than a fixed clock, so the quote says so rather than leaving you to assume otherwise.

Five questions to ask back

1. What is explicitly not included, and what would it cost to add?
2. How is a change priced after we sign?
3. What does support cover, what is a billable extra, and how do you decide what gets done first?
4. Which of these costs are licences or hosting, and are they registered in my name?
5. What exactly do I receive at the end, and is the handover described and priced here?

A supplier who answers all five in writing has given you a better quote than the one you asked for. Hesitation on the basics is an answer too, and so is an answer that arrives by phone and never makes it onto the page.

Before you ask for a quote

If you are earlier than that, our project scope estimator gives a first size for your idea and a scope brief you can hand to any supplier. Sending the same brief to everyone is the simplest way to get quotes you can compare, because the differences between them will be in the terms rather than in what each supplier guessed you meant.

The full list of questions, including the ones about who owns what and what happens if the partner disappears, is in our software partner checklist. Take it to the conversation, and keep the answers.