Compare software development proposals by normalising scope first and price last. Build one feature list, mark what each supplier includes, excludes or leaves ambiguous, then price the gaps yourself. Two quotes that differ by half almost always differ in coverage rather than in day rate, and the cheaper one usually excludes the admin panel.
This guide covers how to normalise proposals, what the price differences actually mean, which contract terms decide the total cost, and how to score suppliers on something other than the number at the bottom.
Key takeaways
- The ambiguous column is the risk: Anything neither included nor excluded gets decided after you sign, when your leverage is gone.
- Ask for the assumed person-days: At $300–$450 per person-day, day count tells you more about scope than rate does.
- Rate explains regions; assumptions explain shortlists: Between similar suppliers, the gap is what each one assumed.
- Compare three years: Support, change rates and ownership terms move the total more than the build price.
Build one feature list and map every proposal to it
Take the union of everything mentioned across all proposals, plus the things none of them mention, and put it in one column. Mark each proposal against every line: included, excluded, or unclear.
The unclear column is what matters. Anything neither included nor excluded will be decided later, when you have already signed and the commercial leverage has moved to the supplier.
Lines routinely missing from every proposal: the admin and back-office interface, data migration, each integration named individually, user acceptance testing, app store submission and review handling, analytics instrumentation, and the first month of post-launch fixes.
Understand what the price differences mean
| Difference | What it usually indicates |
|---|---|
| Region and day rate | Comparable work bills at roughly $15–$160 per hour worldwide; a three-fold gap can be entirely rate |
| Assumed scope | One supplier includes design, another expects you to provide it |
| Quality bar | Testing, security review and accessibility included or omitted |
| Team seniority | Who actually builds it, and whether it is subcontracted |
| Ownership terms | Code, accounts and post-launch support included or charged separately |
Across regions, rate explains most of the difference. Between three proposals on the same shortlist at similar rates, it almost never does, there the gap is assumptions, and that is what you have to surface.
Convert every quote into person-days
Day rates in this segment commonly run $300–$450. Dividing a quote by a plausible rate gives you the supplier's assumed effort, and effort is far more revealing than price.
A $30,000 proposal implies roughly 70–100 person-days. If one supplier has assumed 70 days and another 160 for the same written scope, they are not describing the same project, and one of them will be right.
Ask each supplier directly for their assumed day count by phase. Teams that estimate will answer readily; teams that priced from a feature list will not.
Read the estimate structure, not just the total
A proposal broken into phases with per-feature estimates can be interrogated. A single number cannot.
Ask which items each supplier is least confident about. Experienced teams answer readily and usually name integrations, data migration, or a feature whose business rules are unsettled. A supplier presenting everything as equally certain has either not estimated it or is not telling you.
Check whether contingency is included and how it is treated. A stated contingency is honest planning; a hidden one becomes a change request.
Settle the terms that decide the total
| Term | What to establish |
|---|---|
| Code ownership | Yours from day one, in a repository you control |
| Accounts | Hosting, domain, app store and third-party services in your name |
| Change requests | The rate, the approval process, and whether changes displace scope or add to it |
| Support | Cost after launch and the committed response time |
| Warranty | What period covers defects, and what counts as a defect rather than a change |
| Exit | What is handed over if the engagement ends, and in what state |
A proposal 20% cheaper on build with no support commitment is usually the more expensive purchase over three years.
Choose the commercial model deliberately
Fixed price suits well-defined scope unlikely to change, and you pay a premium for the certainty. It creates an incentive to interpret scope narrowly, so the specification must be precise, difficult before discovery has happened.
Time and materials suits evolving products but needs a cap, a written change process, and regular demonstrated progress rather than status reports.
The middle path is usually the most honest: a paid discovery priced separately, then a fixed or capped price for a first release scoped from what discovery found. It prices the unknown work only after it is known.
Score on more than price
Build a simple matrix and weight it before you see the numbers, so the scoring is not retrofitted to a preference.
| Criterion | What you are testing |
|---|---|
| Relevant delivery evidence | Products they built and still support, not just launched |
| Named team | Who actually builds it; employed or subcontracted |
| Discovery approach | Whether they ask about exceptions and existing systems |
| Communication | Response quality during the sales process predicts delivery |
| Commercial terms | Ownership, change rates, support, exit |
| Normalised price | The figure you recalculated, not the one you were sent |
Recalculate before deciding
Once the feature list is normalised and the gaps priced, recompute every proposal on the same basis and compare those numbers rather than the ones you received.
The ranking often changes. When it does not, you have at least bought the ability to hold a supplier to a scope you both understood, which is worth more than the difference between the quotes.
Related guides
- Alongside How to Compare Software Development Proposals, continue with How to Build a Business Case for Custom Software.
- Alongside How to Compare Software Development Proposals, continue with How to Choose a Digital Transformation Partner.
If the work prompted by How to Compare Software Development Proposals leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Software Project.
Ali Boran Gazel