Why proposals for one project look so different
Send the same brief to four companies and you may receive prices that differ several times over. It is tempting to conclude that someone is overcharging or someone does not understand the work. More often, each company has filled the gaps in the brief with its own assumptions, and priced a different project.
One assumes you will supply all content and test data. Another includes design, a third only development. One prices a first release, another the whole vision. Until those differences are laid side by side, the totals at the bottom mean very little, and choosing by them rewards whoever assumed the least.
First, make the proposals comparable
Build one table with a row for each part of the work and a column for each proposal. Mark each cell as included, excluded, assumed or not mentioned. The not mentioned cells are your questions back to the companies.
| Part of the work | What to look for | Typical gap |
|---|---|---|
| Discovery and requirements | Who writes the detailed requirements, and when | Assumed to exist already |
| Design | Interface design, user testing, number of review rounds | Development only, design assumed supplied |
| Features | A list specific enough to check off | Broad headings that could mean anything |
| Integrations | Each outside system named, with who provides access | Described as simple, with no detail |
| Data migration | What is moved, cleaned and verified | Left out entirely |
| Testing | Who tests, on which devices, and acceptance criteria | Mentioned in a single line |
| Launch and hosting | Environments, release, monitoring | Stops at delivery of code |
| After launch | Warranty period, support, ongoing costs | A separate contract, not priced |
Send every company the same follow-up questions and the same deadline. How quickly and how precisely they answer is evidence in its own right.
Read the assumptions and exclusions first
The summary page is written to persuade. The assumptions and exclusions are written to protect the company, which makes them the most candid part of the document. A proposal with a thoughtful list of assumptions comes from people who have pictured doing the work. A proposal with none has either understood everything perfectly or not thought about it.
Reassuring
- Assumptions that are specific to your project
- Open questions listed, with how each affects the price
- Exclusions stated plainly, with an option to add them
- Risks named, with what the company would do about them
Worth questioning
- No assumptions at all
- Generic text that could apply to any client
- A fixed price with a vague scope
- Everything described as straightforward
Decide what you are scoring, before you read
Agree the criteria and how much each one counts before anyone opens a proposal. Otherwise the most polished document, or the most likeable salesperson, sets the criteria for you. Six areas cover most decisions.
- 01
Do they understand the problem?
What a strong proposal showsThe proposal restates your goal in its own words, questions something in your brief and proposes what to build first.
- 02
Is the scope specific?
What a strong proposal showsYou could tick items off at delivery. Each integration and each role is named.
- 03
Who will do the work?
What a strong proposal showsNamed people or at least defined roles, with how much of their time, and who you will talk to every week.
- 04
How will the project run?
What a strong proposal showsHow often you see working software, how changes are handled and how acceptance is decided.
- 05
How is the price built?
What a strong proposal showsWhat is fixed, what is estimated, what triggers extra cost and what running costs follow launch.
- 06
What happens when things go wrong?
What a strong proposal showsWarranty, support, and the terms on which you could leave with your code and data.
A worked example
Three proposals for an order management system
This example is invented to show the method. A distributor receives three proposals for the same system. The amounts are illustrative units, not real prices.
- Before alignmentA quotes 60 units, B 110 and C 95. A looks like the obvious choice.
- After alignmentA has excluded data migration, the ERP integration and testing on phones. With those added at A's own rates, its price rises to 100 units.
- What decided itB questioned the brief, proposed a smaller first release and named the two people who would lead the work. C had the most precise scope and thinner answers on process.
| Criterion | Weight | A | B | C |
|---|---|---|---|---|
| Understanding of the problem | 25 | 3 | 5 | 4 |
| Specific scope | 20 | 2 | 4 | 5 |
| Team and communication | 15 | 4 | 4 | 3 |
| Process and visibility | 15 | 3 | 5 | 3 |
| Price structure | 15 | 5 | 3 | 4 |
| Risk and exit terms | 10 | 2 | 4 | 4 |
| Weighted total, out of 500 | 100 | 310 | 425 | 395 |
The distributor chooses B, and uses C's detailed scope list as a checklist during contract discussions. The cheapest proposal turned out to be the least complete, which is the most common result of lining proposals up.
Understand how each price is built
| Structure | What it means | Suits | Ask |
|---|---|---|---|
| Fixed price | A set amount for a defined scope | Work that is well specified | What counts as a change, and what does a change cost? |
| Time and materials | You pay for time spent, at agreed rates | Work that will be discovered as it goes | What is the estimate, and how will I see spending against it? |
| Fixed price per phase | Each stage is priced when the one before is done | Larger projects with real unknowns | What do I hold at the end of each phase if I stop? |
| Retainer | A set amount of capacity each period | Ongoing development after launch | What happens to unused time? |
No structure is safer in itself. A fixed price on a vague scope simply moves the argument to what was included. Time and materials without visibility is an open cheque. The protection in each case is specificity and regular sight of working software.
A scorecard you can copy
Proposal evaluation scorecard
TemplateBefore reading
Criteria and weights agreed by everyone who will vote
One person named to collect follow-up questions
Alignment
Scope table completed for every proposal: included, excluded, assumed, not mentioned
Follow-up questions sent to all companies with one deadline
Prices adjusted so that each covers the same scope
Scoring, one to five for each proposal
Understanding of the problem
Specific scope
Team and communication
Process and visibility
Price structure and running costs
Risk, warranty and exit terms
Before deciding
References spoken to, with the same questions for each
The people who will do the work met, not only the people who sell it
Contract terms read alongside the proposal
What to do next
If proposals are already on your desk, build the scope table today. It usually takes an afternoon and changes the ranking. If you have not asked for proposals yet, a clearer brief will make them more alike from the start, and our guide to choosing a development partner covers the steps before this one.
We are glad to be one of the companies you compare. Send us your brief and judge our proposal by the criteria above.
Common questions
Why do software development quotes vary so much?
Mainly because each company prices a different interpretation of the brief. Scope, assumed client responsibilities, the seniority of the team, the amount of design and testing, and whether launch and support are included all differ. Location and overheads matter as well. Until you have lined up what each quote covers, the spread tells you more about the brief's gaps than about value.
Should we choose the cheapest proposal?
Only if it covers the same scope as the others and scores well on your other criteria. The lowest price often reflects exclusions or optimistic assumptions that reappear later as change requests. Adjust every price to the same scope first. If the cheapest is still the cheapest and its authors clearly understand the work, it may well be the right choice.
How many proposals should we ask for?
Three or four is usually enough. Fewer leaves you without a real comparison. Many more consumes your time, and serious companies invest less effort when they know they are one of ten. It is better to shortlist carefully, give each company a proper conversation and a clear brief, and receive proposals that were written with care.
Is a fixed price safer than time and materials?
It feels safer, and for a well-specified piece of work it can be. When the scope is still uncertain, a fixed price either carries a large margin for risk or leads to disputes over what was included. Many projects work best with a fixed-price discovery or first phase, followed by a structure chosen with better information.
What should we ask references?
Ask what went wrong and how the company handled it, since every project has difficulties. Ask whether the people named in the proposal were the people who did the work, how changes were priced, whether estimates held, and whether the client would hire them again for a similar project. Put the same questions to each reference, so the answers can be compared.
