How do I choose between different development quotations?
Send each supplier the same brief and compare deliverables, assumptions, exclusions, operating costs, ownership and support. Ask them to demonstrate the same important workflow. Make the acceptance evidence explicit, so the quotation with the lowest total is not simply the one containing the least work.
The key idea
A useful comparison explains what you will receive, who will operate it and what could change the cost. Price becomes meaningful after the scope is aligned.
Give suppliers one business story to work from
For an illustrative delivery business, describe customer booking, address confirmation, staff assignment, status updates, payment exceptions and completion. Include cancellation and a missed appointment. List the languages, existing systems, users and launch priorities. That common story is easier to compare than a collection of unrelated screenshots.
Ask each supplier to label what already exists, what needs custom work and what depends on a third party. Require written assumptions rather than accepting a friendly “yes” in a meeting. Keep open questions in the brief and distribute relevant clarifications consistently. You do not need a perfect technical specification to ask for comparable answers.
Turn package names into a comparison sheet
Use rows for customer screens, staff screens, integrations, data migration, content, language review, testing, training and handover. Record whether each is included, limited, optional or excluded. If an item is unclear, ask for a definition and keep the answer with the proposal.
The illustrative table below shows why equal labels can hide different work. It does not price a real supplier. A page count does not establish how bookings work, and an “admin panel” does not explain permissions. Ask what a staff member can actually do and which exception cases are covered.
In practice · illustrative example
Compare the exception every supplier must handle
For an illustrative booking system, ask every supplier how it handles a request for an unavailable time. One proposal may offer a basic calendar; another may include staff review and alternative suggestions. Put that difference beside the price. A lower total for a different outcome is not a like-for-like comparison.
Have the suppliers identify the assumptions behind their approach. Who provides the schedule? Who approves content? Which external account must be ready? Turn the answers into deliverables, dependencies and exclusions. Ask the operational owner to review them before approving the final proposal, while a misunderstanding is still inexpensive to resolve.
Make the comparison follow one business story
-
Common task
Every supplier receives the same customer action and exception.
-
Explicit outcome
The proposal describes what customers and staff can actually do.
-
Visible assumptions
Dependencies, exclusions and business inputs are written down.
-
Comparable acceptance
The team reviews the same working journey before approval.
Separate project fees from operating assumptions
Identify initial development, hosting, licences, store accounts, payment-provider services, support and renewals. Ask which charges come from the supplier and which you pay directly. Record any usage assumptions, such as users or transaction volumes, and what happens when they change.
Compare quotations in a consistent currency and with the same stated treatment of applicable charges; let your finance team review the details. Do not invent market averages to judge an unfamiliar project. Request an optional-feature breakdown so you can reduce scope without silently removing something essential to the launch.
Agree how you will recognise completed work
Use observable tasks: a customer submits a booking, staff change its status with the right permissions, and the customer sees the correct result in both languages. Include a failed payment, a changed address and an unavailable service. Name who approves each test and how defects will be recorded and corrected.
NIST’s secure-development framework offers useful context for asking about development and security practices. Ask for project-relevant evidence, not a vague promise that the software is secure. Confirm who reviews access controls, updates, dependencies and incident handling, with the depth appropriate to the information the product will handle.
Check who delivers and what happens after launch
Meet the proposed delivery lead and clarify the role of partners. Request a relevant approved reference or a demonstration, and distinguish a concept from delivered work. Ask who responds after launch and how changes, outages and recurring maintenance are handled.
Record the agreed ownership and handover package: repositories, account access, design files, documentation, training and data export where relevant. Have the appropriate contracting reviewer confirm the written terms. A clear proposal should make ongoing responsibility visible rather than leave it to an assumption that “we will sort it out later”.
A worksheet for your team
A proposal clarification sheet
Send the unresolved lines back to each supplier before the final decision.
| Decision | Evidence to request | What to do next |
|---|---|---|
| Difficult case | The unavailable slot or other relevant exception. | Ask for the customer and staff outcome. |
| Business input | The content, schedule or account the company must supply. | Assign its owner and delivery responsibility. |
| Acceptance | A check demonstrating the agreed outcome. | Attach it to the approved scope. |
Keep clarifications with the final proposal. They are part of what you are buying and help the delivery team avoid reopening settled decisions.
Keep these records with your decision
- One brief and a shared clarification record.
- Included, optional and excluded deliverables.
- Initial and recurring cost assumptions.
- Comparable demonstrations and acceptance tests.
- Named delivery and support responsibilities.
- Written ownership and handover arrangements.
Compare your options
| Item | Possible ambiguity | Question to resolve it |
|---|---|---|
| Bilingual content | Translation excluded | Who writes and approves each language? |
| Staff interface | Basic panel only | Which roles and exception tasks are included? |
| Integrations | Named without a scope | What data moves, and who handles failures? |
| Support | No defined arrangement | What is covered, by whom and for how long? |
Frequently asked questions
Is the cheapest proposal always the best value?
First check whether it contains the same scope and operating responsibilities. A lower total may be appropriate, or may exclude work you still need. Compare the complete plan against your priorities.
What if I do not know the technical terminology?
Describe the user task and ask the supplier to explain its proposed solution, assumptions and evidence in plain language. An independent discovery or review engagement can help align proposals.
Should I require the same framework from every supplier?
Only where there is a real constraint. Explain your existing systems, maintenance needs and integrations, then ask suppliers to justify the technical approach. Evaluate the consequence for your business rather than choosing a name alone.
Sources and further reading
These primary sources support the specific company or platform information in this guide. Provider descriptions do not imply an endorsement by the source.
Sources checked:
Make your software brief easier to compare
Share your workflow and the decisions that remain unclear. GateGold can discuss a discovery or technical consulting scope before development begins.
