Start here.
Compare what each proposal promises to deliver before comparing the totals. Ask each supplier to explain the same customer or staff journey, what is included, what you must provide, how you will check the work, and what you will pay for after launch. Get unclear answers written into the proposal.
- You can ask for an explanation in ordinary language before agreeing to anything.
- A missing detail is a question to resolve, not proof that a supplier has excluded it.
- Keep a written list of open questions so you can compare the revised proposals fairly.
Are they quoting for the same finished job?
Imagine you want a customer area for your business. Customers would sign in, see how their job is progressing, and approve a document when you need a decision. This is an invented example, not a client project or a pair of real quotes.
One proposal says “customer portal”. Another lists customer accounts, document approvals, email updates, and staff training. You cannot tell from those descriptions alone whether the second includes more work or simply explains the same work more clearly.
Ask both suppliers to walk through one ordinary job: a customer receives access, checks their progress, opens the right document, and approves it. Then follow what your staff need to do before and after that approval.
Put the answers beside each other. The following fictional comparison shows questions that still need resolving before the prices can be compared.
| What needs to be clear? | Proposal A | Proposal B |
|---|---|---|
| How progress is updated | Not explained | Staff change the job status on a separate screen |
| What a customer can approve | “Document approval” listed | One document at a time; changes require a new approval |
| How existing customers are added | Customer list supplied by the business | Help preparing and importing the customer list included |
| Who introduces it to staff | Not explained | One staff training session included |
| Help after launch | Support mentioned; terms unclear | An initial support period described; ongoing help quoted separately |
What is included, and what would cost extra?
Ask the supplier to separate what they will build now, what can wait, and what they have assumed someone else will provide. “Payments”, for example, could mean sending customers to an existing payment page or building a place to pay inside the new application. Those are different descriptions of the work.
Give special attention to anything your business cannot launch without. If staff must see a customer’s existing orders, ask whether connecting those orders is included. If the answer depends on another company’s software, ask what has been checked and what remains uncertain.
You should also understand how a change would be priced. Suppose you later decide that a customer needs to approve several documents together. Ask how the supplier would explain the extra work, agree the cost with you, and show any effect on the launch date before proceeding.
The aim is to understand the boundary of the quote. An assumption you discover together now is easier to discuss before you have planned the launch around it.
What will your team need to do?
A proposal can include the software while leaving important preparation with your business. You might need to supply wording, organise old records, choose which staff can see which information, or arrange access to an existing tool.
Ask for a short list of those jobs, who needs to do each one, and when it is needed. For the customer-area example, someone needs to decide which customers to invite first and make sure their contact details are usable.
Check whether the suggested timetable leaves room for your side of the work. If the person who must review the designs is away during that period, the calendar needs discussing. A launch date is more useful when everyone knows what it depends on.
How will you know the work is ready?
Ask when you will see working software and what you will be asked to review. A picture of a screen can help you judge the layout. You will also need to try the actual tasks before deciding the application is ready to use.
For our invented customer area, you could check that a customer sees the right job, can open the current document, and understands what approving it will do. Your staff could check that the approval appears where they expect it. You would also want to test what happens when someone needs a correction.
Use made-up records while testing. Ask the supplier how access will be checked, including whether one customer can see another customer’s information. You can ask to see the result without needing to understand the code.
Agree how you will report problems, which ones need resolving before launch, and how the business will decide it is ready. Keep those checks attached to the work people need to finish.
What happens after the launch?
Ask for the costs and responsibilities that continue after the initial build. These may include hosting, services the application relies on, maintenance, and help for your team. Find out which are included, which are separate, and which depend on how much the application is used.
Compare the proposed cost of getting through the first year and then a following year. Keep assumptions visible rather than treating every future charge as a known amount. You are trying to understand the commitment, not predict every possible change.
Also ask who will control the important business accounts, what you will receive at handover, and what would be needed if another company maintained the software later. Request a clear written answer about ownership and access; have any contract terms you do not understand explained by an appropriate adviser.
Support deserves a specific conversation: how do you report an urgent problem, when is help available, and who is responsible for responding? A promise of “ongoing support” leaves those questions open.
How do you make the final choice?
Send each supplier the same remaining questions and ask for an updated proposal or a written clarification. Give them a chance to resolve gaps. Comparing a detailed second draft with someone else’s first estimate can otherwise make the decision misleading.
Once the work is clear, consider the price alongside the proposed approach, the responsibilities your business can manage, and how comfortably you can work with the people involved. Notice whether they explain tradeoffs, answer direct questions, and are willing to say what they have not established yet.
If you still cannot describe what you would receive and what happens next, ask for another conversation. The point of comparing quotes is to reach an agreement you can understand and work from.
Bring the proposals and your unanswered questions.
A useful comparison can start with the documents you already have. You do not need to turn them into a technical specification first.
- The versions you are comparing
- Keep the date and version of each proposal so a later clarification is not lost in an older document.
- The promises that matter
- Mark anything you are relying on, especially a launch date, a particular customer task, or a tool you need to keep using.
- The words you cannot explain
- Highlight terms you would struggle to explain to a colleague. Ask what they mean for your project.
- The decision you need to make
- Explain when you need to choose and who else in your business should be involved.
A couple of common questions.
What if a supplier needs paid planning before giving a detailed quote?
Ask what that planning would produce, what it costs, and whether you could use the resulting documents with another supplier. You should be able to judge the planning step as a separate purchase, including what decision it will help you make.
How should we compare a fixed price with an hourly proposal?
Ask each supplier to explain how billing would work for the same agreed tasks. For hourly work, ask about the estimate, how spending is reported, and what happens as it approaches your limit. For a fixed price, ask which assumptions and changes could affect the total. Compare the answers in writing.