You asked three suppliers for a quote on an internal tool. The first came back with one page and a single figure. The second ran to twelve pages. The third is the cheapest and promises everything. Which one is the best offer?
You cannot tell from the total. A quote is a description of a plan, and the plan is what you are buying. This article is for the person who orders the work, such as a head of operations or finance, and who does not need to read code to judge a quote. It gives you a checklist, three warning signs and a list of questions. It does not discuss prices, because those depend on your case.
What a good quote contains
Read the quote and look for these six things. If one is missing, that is your first question.
- The outcome in plain words. What will people be able to do after the work that they cannot do now? "A customer portal" is a thing. "Account managers can see an order's status without calling the warehouse" is an outcome.
- The scope, listed. Screens, reports, integrations with other systems, user roles, data to be moved from the old tool. A list you can tick off, not a paragraph of adjectives.
- What is not included. Good suppliers write this down, because they have seen the misunderstandings. If there is no exclusions section, the exclusions still exist; you will just find them later.
- Assumptions. What the estimate takes for granted: that your data is in a usable state, that someone from your side answers questions within a day, that you supply test accounts for other systems.
- The stages and what you see at the end of each. Even a small project should show something working before the end. Our article on what discovery should prevent in custom software explains why an early, short stage is where many costly mistakes are caught.
- How change is handled and what happens after delivery. Who owns the code, who fixes defects and for how long, what a new request costs and how it is approved.
Three warning signs
1. The scope is vague
Phrases such as "a modern, user-friendly platform", "all necessary integrations" or "standard features" cannot be checked. When delivery comes, you and the supplier will read them differently, and the difference will be expressed in money and time.
A simple test: could a third party, given only the quote, decide whether a particular feature is in or out? If not, the scope is vague. Ask the supplier to name the five or ten things that matter most and to say clearly what each one includes.
2. The number does not match the work
A total with no breakdown is hard to judge. Two opposite problems are common. A very low figure often means the supplier has understood less than you think, and the rest will come back as changes. A very high figure with no explanation may include a large margin for risk that nobody has described.
You do not need an itemised price for every button. You need to see roughly where the effort sits: understanding the problem, building, testing, moving data, training, and handover. If testing and data migration are missing, someone expects them to be free.
If you are choosing how to pay, our article on fixed price or time and materials explains which contract fits which stage. Either can work, but the quote should say which one it is and what that means for changes.
3. Nothing about change or handover
Requirements change while work is under way, because people see the first version and notice what they really need. A quote that does not say how this is handled leaves the question open for the most tense moment of the project.
The same goes for the day after delivery. Who hosts the tool? Who answers when it breaks? Can another supplier take over? Our piece on years two to five of custom software shows how much of the real cost lies after the first release. A quote that stops at go-live describes only part of it.
Questions to ask before you sign
Send these in writing and ask for written answers. Keep the replies with the quote.
About scope
- What is explicitly not included?
- Which two or three items in the scope are you least sure about, and why?
- What do you need from us, and by when, for the estimate to hold?
About change
- If we change a requirement after work has started, how is the effect on time and cost shown and approved?
- Is there a set amount of time for small adjustments, or is every change a separate request?
- What would make this estimate grow, and how soon would you tell us?
About results
- What will we see at the end of the first stage, and how will we decide it is good enough to continue?
- How will the work be tested, and who from our side takes part?
- Can we stop after a stage and keep what has been built?
About ownership and the future
- Who owns the code and the data, and in what form do we receive them?
- Who can maintain the tool if we part ways, and what documentation do we get?
- What are the running costs after launch, such as hosting, licences of other products, and support?
A supplier who answers these calmly and concretely is showing you how they will work. One who gets irritated, or answers "don't worry about that", is showing you the same.
Compare quotes by their assumptions
When you have two or three quotes, put them side by side in a table with one row per item from the checklist: outcome, scope, exclusions, assumptions, stages, change, handover. Fill in what each supplier wrote and mark the empty cells. Only then look at the totals.
Often the cheapest quote has the most empty cells. That does not make it wrong, but it tells you the price excludes something. Ask the supplier to fill in the cells, and compare again. If you are weighing building against buying a ready-made product before you request quotes at all, our article on the five questions before you decide is a good place to start.
What to do this week
On Monday, take the quote you have and mark each of the six items as present, vague or missing. On Tuesday, send the supplier the questions that match the gaps. On Wednesday, ask a colleague who will use the tool to read the scope list and say what they expected to see and did not. On Thursday, put the answers next to the quote and decide whether the plan is clear enough to sign, or whether you need a short paid first stage to clear it up. On Friday, write down the three assumptions about your own side, such as data, availability and decisions, and name a person who is responsible for each.
Sources
- Our related articles linked above.
- The checklist is a general method and does not describe a particular supplier, quote or price.