Contents
Read a software development quote from the scope, not the total: what will be built, by whom, in what unit and with what buffer. A good quote is broken down by scenario and includes discovery, testing, launch and a buffer for unknowns; a poor one is a single number or a list of screens with hours.
Here is what a quote consists of, how to check each line and what to ask the vendor.
What does a development quote consist of?
A development quote consists of work stages, their estimates in hours or money, the roles doing the work and the terms: what is included, what is not and which assumptions were made. The total is derived from all of this and says nothing about estimate quality on its own.
The essential parts of a good quote:
- discovery and design — scenarios, prototypes, architecture;
- UI design, if designs are not ready;
- development broken down by functional block;
- testing and bug fixing;
- launch: server setup, monitoring, backups;
- project management;
- a buffer for unknowns, with an explanation of where it comes from;
- a list of assumptions and exclusions.
We showed typical shares for these parts in how much an MVP costs.
How do you check the development breakdown?
Check that the development breakdown maps to real product scenarios: each line should correspond to a complete user action or a system module, not an abstract "backend development". If you cannot tell from a line what will appear in the product, you cannot check the estimate.
A line you can check:
Scenario "Pay for an order" estimate
front end — cart, payment method, status 16–24 h
backend — payment, bank webhook, receipt 24–32 h
admin — payments list, refunds 8–12 h
tests — success, decline, repeated webhook 8–12 h
total 56–80 h
And one you cannot: "Backend — 400 hours". It is unclear what is included, where the risks are and what can be cut if the budget runs short.
A range beats a single number
An honest early estimate is a range, not one number. The width of the range shows how much uncertainty remains: narrow means the requirements are clear, wide means there are questions worth closing before you start. An exact number with no range on vague requirements means either a large hidden buffer or future change orders.
Photo: Unsplash
How do you assess rates and roles?
Assess rates and roles together: what matters is not just the hourly rate but who does the work and how many hours go to each role. A quote that prices everything at one blended rate hides how much time goes to senior specialists and how much to juniors.
| What to check | Good sign | Worth asking about |
|---|---|---|
| Roles | Listed: analyst, designer, developers, QA, manager | Just "development" |
| Rates | Given per role | One blended rate for everything |
| Project management | 10–15% of the work (our benchmark) | None at all, or more than a quarter |
| Testing | A separate line or explicit in each block | Not mentioned |
| Buffer for unknowns | Named and justified | Missing despite vague requirements |
| Assumptions | Listed explicitly | None |
What are the signs of an underpriced or overpriced quote?
An underpriced quote usually lacks testing, launch and a buffer; an overpriced one treats simple things as complex or includes work the product does not need. Both show up when you compare lines rather than totals.
Signs of an underpriced quote:
- No testing or bug fixing.
- No launch or infrastructure setup.
- Integrations with third-party services estimated at a couple of hours.
- No buffer despite clearly incomplete requirements.
Signs of an overpriced quote:
- Microservices, Kubernetes and complex infrastructure for a product with no users.
- Custom development of things an off-the-shelf service already does.
- Features that are not in your requirements "because it's best practice".
- Equally large estimates for simple and complex blocks — a sign of guesswork.
What should you ask the vendor about the quote?
Ask questions about the quote to understand the estimating logic, not to haggle. A good vendor willingly explains what drives each line and what can be simplified — it is a normal part of the job.
What to ask:
- Which assumptions underlie the estimate, and what happens if they turn out wrong?
- Which lines are the riskiest, and why?
- What can move to version two, and how much would that save?
- How are requirement changes during the work billed?
- What does the warranty period after launch cover?
The pricing model also affects how to read a quote: with a fixed price the buffer is already in the total; with time-based billing the range and caps matter more. See fixed price vs Time & Materials.
In short
- Read a quote starting from the scope, not the total.
- Every development line should map to a scenario or module you can verify.
- An honest early estimate is a range; its width shows the uncertainty.
- Check roles, rates, testing, launch, the buffer and explicit assumptions.
- Ask about risks and what can wait — the best way to lower the price without losing quality.
FAQ
Why do quotes from different vendors differ so much?
Most often because they describe different scope: some include testing, launch and a buffer, others do not. Rates, team experience and how each vendor understood the requirements also differ.
What are story points, and can a budget be based on them?
Story points are a relative measure of task complexity inside a team. For budgeting they are converted into hours or money using the team's actual velocity, so hours or cost are clearer for a client-facing quote.
Can we negotiate on a quote?
Yes, but cutting scope works better than cutting the rate. Moving a feature to version two lowers the price honestly, while pressure on rates often turns into savings on testing and quality.
