How to review a software estimate: six signs the quote is understated
We look at other people’s quotes regularly: a client forwards a proposal from another vendor and asks whether it is reasonable. One review ended with a sentence we keep reusing: the arithmetic was flawless, and the scope was understated roughly threefold.
It was a marketplace with augmented reality eyewear try on. Even the vendor’s pessimistic scenario sat below our trimmed optimistic one. Here are the six signs that make this visible before anything is signed.
One: work that has to happen is not in the quote
Check whether the document contains lines for discovery, architecture, infrastructure and environments, integrations, stabilisation and bug fixing, release with documentation, and project management.
None of this is optional. If those lines are missing, the work has not disappeared, it has simply not been counted. Three outcomes follow: the vendor absorbs it and runs at a loss, comes back for more budget, or skips it, and you receive a product with no documentation, no environments, and bugs nobody is assigned to fix.
Two: the hardest part occupies a single line
In that marketplace quote the sharpest risk was compressed into one item: a complex payment integration together with multi vendor support, at an hour count that covers a fraction of the work.
A quick test: find the most technical line in the quote and look at the hours next to it. If integrating with somebody else’s system is budgeted below the page markup, the quote was written without opening that system’s documentation.
Three: the range is cosmetic
A good quote gives three numbers. So does a bad one, which is why you look at how they were produced, not whether they exist.
The tell is that every scenario differs by the same coefficient. That spreads uncertainty evenly, when in reality it sits in two or three specific blocks. In a real three point estimate the markup barely moves between scenarios while the integration doubles.
There is a worse variant. If the base estimate is already optimistic, the entire range, pessimistic case included, sits below a realistic expectation. The document looks cautious while leaving no slack at all.
Four: the rate is below market
Understating hours and understating the rate compound. Ask directly whether the rate is cost or sale price. If a vendor quotes noticeably below the market rate for the required seniority and region, their cost eats almost the entire price.
For you this is not a discount. It is the probability that the team abandons the project midway, or starts economising on the parts you cannot see: testing and architecture.
Five: the schedule assumes 160 hours a month
If the timeline is built as though a developer produces 160 useful hours a month, it will slip. Real output is roughly 120 to 130 hours. The rest goes to calls, reviews, context switching and answering questions.
We ran into this on our own estimate for an education platform. The first version was built from market rates and produced a multi million rouble range. After correcting for real capacity it became clear the full scope was months of work for one person, and the choice was down to three options: cut scope, extend the timeline, or decline. Saying that before the start is cheaper than discovering it in month three.
Six: nothing about life after launch
Delivery is not the end. Servers, domains, certificates, updates, monitoring and fixes remain. If the quote says nothing about them, after launch you own a product with no maintainer.
While you are at it, ask whose accounts will hold the domain, hosting and repository. The correct answer is yours, from day one.
Three questions that replace the whole review
If you have no time for the full analysis, ask for three things.
Show the breakdown by blocks of work. Show the assumptions the estimate was built on. Show how the minimum and the maximum were derived.
A quote that cannot be taken apart cannot be verified by anything except trust in its author. You are not checking the number, you are checking what the number is made of.
There is an uncomfortable corollary. The vendor who brings a complete estimate always looks more expensive than the one who brings an incomplete one. The cheap proposal wins the tender, the expensive one survives to delivery, and the difference between them is usually not greed. It is whether somebody counted the integrations.
FAQ
Why is a low quote a risk rather than a saving
Because the missing work does not disappear. It resurfaces mid project as a request for more budget, a reduced scope, or work stopping altogether. On a fixed price contract an understated quote is dangerous for both sides.
What is a three point estimate
Minimum, expected and maximum calculated per block of work rather than derived from one another. It shows where the uncertainty actually sits instead of hiding it behind a single number.
Which blocks are missing most often
Discovery, architecture, infrastructure and environments, integrations, stabilisation, release with documentation, and project management. These are exactly the tasks that have to be done regardless of whether anyone budgeted for them.
Can I compare vendors by the total price
Only if both quotes cover the same scope, which they almost never do. Compare the list of work and the assumptions, otherwise you are comparing a full project with a part of one.