Comparing Software Proposals Beyond Price: What Each One Actually Includes
In short
To compare software proposals fairly, put them side by side on the same rows before looking at price: what each assumes, what it excludes or never mentions, how the work will be accepted, who owns the code and accounts, what support follows launch, and how changes are agreed. Proposals that differ sharply in price usually differ in these rows, because they are quoting different work.
Key takeaways
- The cheapest proposal may simply include less. Before comparing prices, check that the proposals are quoting the same work.
- Read every assumption as scope with a condition attached. If the condition fails, the cost and the timeline move.
- "Not mentioned" is a third answer, different from included or excluded, and the one most likely to become a disagreement later.
- Compare how the work will be accepted, who owns the code and accounts, and what support follows launch. These are part of what you are buying.
- Send every supplier the same questions in writing, starting with "what is not included?", and compare the answers on the same rows.
Table of contents
Three software proposals arrive for the same project. One is a two-page summary, one is a long document with a timeline, one is a spreadsheet. The totals are far apart, and the natural move is to compare the totals: pick the cheapest, or distrust it and pick the middle.
Both choices skip the question that matters. The cheapest proposal may simply include less. Before price means anything, you need to know whether the three are quoting the same work, and usually they are not.
This is the step after writing a clear brief. A good software project brief makes proposals easier to compare. It does not make them identical, and even well briefed suppliers make different assumptions about the parts nobody wrote down.
Why software proposals are hard to compare
Software proposals are hard to compare because each supplier describes the project in its own structure, at its own level of detail, with its own idea of what is standard. One lists every screen; another lists outcomes. One includes testing as a line; another assumes it is inside every estimate.
The fix is not to ask for more detail from everyone. It is to take control of the format: build one comparison and make each proposal answer the same rows.
Put the proposals side by side on the same rows
Start a simple grid. The columns are the suppliers. The rows are the things that change what you actually get:
- The scope items from your brief, one per row
- Assumptions each proposal depends on
- Exclusions, stated and implied
- How the finished work will be accepted
- Ownership of code, accounts and data
- Support after launch
- How changes are estimated and agreed
Fill each cell from the proposal's own words. Where a proposal is silent, write "not mentioned" rather than guessing. The gaps are the point.
Read the assumptions as scope
Every proposal rests on assumptions, often in a short paragraph near the end. "Content will be provided by the client." "Integration uses the existing interface as documented." "Designs are based on one round of revisions." "Data will be supplied in a clean format."
Read each one as scope with a condition attached. If the content arrives late, the interface is not as documented, or the data is not clean, the work and the timeline change. A proposal with many optimistic assumptions can look cheaper precisely because it has quietly moved risk back onto you.
Find the exclusions, stated and unstated
Some proposals list what they exclude, which is helpful and a good sign. Others simply leave things out. Common gaps worth checking every time:
- Moving existing data into the new system
- Testing across the devices and browsers your users actually have
- Hosting, environments and deployment
- App store submission, where there is an app
- Training, documentation and handover
- Accessibility, security review and performance testing
For each, the answer is included, excluded, or not mentioned. "Not mentioned" is the most expensive of the three, because nobody agreed it and both sides will remember it differently later.
Check how the work will be accepted
A proposal should say how you will decide the work is finished. Who tests it, against what, for how long, and what happens to defects found after sign-off.
Two proposals with the same feature list can differ enormously here. One includes a testing period against written acceptance criteria and a fix period after launch. Another treats delivery of the code as the end. The second is not necessarily wrong, but it is a different product at a different risk.
Confirm who owns the code, accounts and data
Ownership belongs in the proposal, before anything is signed. Check that the code will live in repositories your organisation owns, that hosting, domains and third-party services are set up in your accounts, and that licences and any reused components are named, with the terms under which you can keep using them.
If a proposal is silent on ownership, ask. The answer is usually fine, and getting it in writing now costs one email. Finding out at the end of a relationship costs far more.
Compare what happens after launch
Launch is when real users find the problems testing missed. Compare what each proposal offers afterwards: a period in which defects are fixed, whether ongoing support is available, how quickly issues are responded to, and who you contact.
Describe each in the grid in plain words. A proposal that ends at launch and one that includes a stabilisation period are not quoting the same project, even if every feature matches.
Ask how changes are estimated and agreed
Every software project changes as it goes. What matters is how. Does the proposal describe how a change is requested, estimated, approved and scheduled? Who can approve it on your side? Is there a written record?
A clear change process protects both sides. Its absence usually means changes get agreed informally in meetings and argued about at invoice time.
An illustrative inclusion comparison
The comparison below is illustrative, not taken from real proposals, and deliberately leaves out prices. It shows how the rows expose differences the totals hide.
| Row | Proposal A | Proposal B | Proposal C |
|---|---|---|---|
| Data migration | Included | Excluded | Not mentioned |
| Device and browser testing | Included, listed | Included | Not mentioned |
| Acceptance period | Two weeks, written criteria | Not mentioned | One week |
| Code in your repositories | Yes | Yes | Supplier's until final payment |
| Fix period after launch | Included | Not mentioned | Included |
| Change process | Written, estimated per change | Informal | Written |
| Assumptions listed | 4 | 11 | 2 |
Proposal B may well be the lowest total. It also excludes migration, is silent on acceptance and post-launch fixes, handles changes informally, and rests on eleven assumptions. It is quoting a smaller, riskier project than A, not the same project for less.
Questions to send every supplier before choosing
Turn the gaps into questions and send the same list to every supplier in writing, so the answers land on the same rows:
- What is not included in this proposal?
- Which assumptions, if wrong, would change the estimate the most?
- How will we accept the work, and what happens to defects after launch?
- Where will the code, accounts and data live, and in whose name?
- How is a change requested, estimated and approved?
The first question is the most useful one. The answers will tell you more about each supplier than the totals did.
If you have proposals on the table that do not seem to describe the same project, that is worth untangling before choosing. Clarify the project scope with us: comparing proposals on the same rows is often where our software development conversations start, even when the work ends up elsewhere.
Frequently asked questions
Put the proposals side by side on the same rows before comparing price: the scope items from your brief, each proposal's assumptions, what it excludes or does not mention, how work will be accepted, who owns the code and accounts, support after launch, and how changes are agreed. Proposals with very different totals usually differ in these rows.
Because each supplier interprets the gaps in the brief differently and structures its proposal its own way. They make different assumptions, include or leave out different work such as data migration, testing or post-launch fixes, and describe it at different levels of detail. The totals differ because they are often quoting different projects.
Beyond the feature list, it should state its assumptions, what is excluded, how the finished work will be tested and accepted, who owns the code, accounts and data, what support follows launch, and how changes are requested, estimated and approved. Anything it does not mention is worth asking about in writing before choosing.
Not necessarily, but the cheapest proposal may simply include less. Check whether it excludes or never mentions things the others include, such as data migration, testing, an acceptance period or fixes after launch, and whether it rests on more assumptions. If it covers the same work on the same rows, the lower price may be genuine.
It means the proposal neither includes nor excludes the item, so nobody has agreed who will do it. That makes it riskier than a stated exclusion, because each side is likely to remember it differently later. Ask every supplier the same question about each unmentioned item and record the answers in writing.
Ask each supplier, in writing: what is not included, which assumptions would change the estimate most if wrong, how the work will be accepted and defects handled after launch, where the code, accounts and data will live and in whose name, and how changes are requested, estimated and approved.
Have a Custom software development project like this in mind?
Tell us what you are trying to build. We will tell you plainly what Custom software development work like this would take.
Get a quoteContact Us
Lahore, Pakistan · London, U.K · Austin TX, U.S · Toronto, Canada