Home › Blog › Reading a development quote

How to read a development quote — what to look at before the total

Put three quotes side by side and compare only the totals and you will usually choose wrongly. The totals differ because the included scope differs, far more often than because rates differ.

What to compare Why cheap is cheap Questions to ask

The short answer

The total is the last thing you read. First scope, then assumptions, then exclusions. If those three differ, comparing totals means nothing.

The cheapest quote is not automatically bad — but you need to know why it is cheap. A narrow reading of scope, maintenance left out, a different team composition. Unexplained cheapness is the dangerous kind.

The order to read in

1. Scope — does the feature list match your document? — A different item count exposes the cause immediately. Mark features that are in your document but not the quote, and vice versa.

2. Assumptions — read the "preconditions" clause first — Usually in small print near the back. Sentences like "assumes an API is provided" or "assumes design mockups are supplied" are what set the total.

3. Exclusions — Check for data migration, design, infrastructure cost and maintenance. Anything left out comes back as cost later.

4. Team composition and duration — Who is assigned, for how many months. The same total buys two seniors for three months or four juniors for three months, and those produce different outcomes.

5. Payment terms and acceptance — Stage payment percentages, the acceptance window, final payment conditions. With no acceptance window, a dispute has no reference point.

6. The total — Only meaningful once the five items above are aligned.

Common reasons a quote is cheap — find out which one

Reason	A problem?	Question to ask
They read the scope narrowly	Yes	Is this feature included, and under which line?
Maintenance and support are excluded	Yes	Is post-delivery support a separate contract? Term and cost?
They have done this before, so it is faster	No	Can we see comparable work?
They reuse existing code or a framework	Conditional	How do ownership and licensing work?
The team is mostly junior	Conditional	What is the review process, and who is accountable?
The schedule is optimistic	Yes	Is there a delay clause in the contract?

Five questions to always ask

Please list every precondition behind this quote — The assumptions are frequently not all written down. Get them verbally if necessary, and record them.

How are scope changes handled? — Whether a change process and its rates are in the contract decides your mid-project cost.

What is included in the deliverables? — Source code, documentation, deployment environment, account ownership. Ambiguous ownership makes switching vendors expensive later.

What are the acceptance criteria and window? — Confirm the definition of done matches your own document.

What are the maintenance terms? — Term, response time, what is covered, cost. This is usually where total cost of ownership is actually decided.

Build the comparison table yourself

Quote formats differ per company, so nothing compares until you move them into a table of your own. Rows are the feature list from your requirements document; columns are the vendors. Cells say included, excluded, or quoted separately.

Building that table usually reveals two things: which vendor actually read your document, and which items in your document were ambiguous. The second is the more valuable finding.

Add the totals only after the table exists. Keep that order and you get to choose the cheapest at equal scope, rather than simply the cheapest.

Frequently asked questions

How many quotes should we get?

Around three is practical. Two makes it hard to see why they differ; five or more makes the comparison work itself a burden. What matters more than the count is that everyone received the same document.

Can we just compare day rates?

Rates are a reference point only. The number of person-months needed for the same feature differs by company, so a low rate can still produce a high total. Total against scope is the measure.

Is it wrong to pick the cheapest?

Not if you have established why it is cheap. Prior experience or reusable assets make cheap rational. Narrow scope or excluded maintenance make it more expensive later.

What if every quote exceeds the budget?

Adjust by feature priority. Asking for a discount across the board quietly reduces quality or scope. Doing the must-haves in phase one and deferring the optional features produces a better result.

Estimate the range

Set the budget range first

The outsourcing cost calculator estimates a cost range by feature scope — use it to fix a budget ceiling before you request quotes.

Estimate cost