How to review a software estimate: six signs the quote is understated

A client forwarded a proposal from another vendor and asked whether it looked reasonable. The document was beautiful: a tidy table, even rows, a total that added up to the last rouble. The arithmetic was fine. The scope was understated roughly threefold, and even that vendor’s pessimistic scenario sat below our trimmed optimistic one.

The project was a marketplace with augmented reality eyewear try on. Heavy work. Below are six things that make this visible before anything is signed, ordered by how often we meet them.

Check whether the invisible work is priced at all

Open the document and look for discovery, architecture, environments, integrations, stabilisation, release and project management. The full breakdown of each block lives in our article on MVP estimates, and what matters here is only whether the lines exist. None of that work disappears because nobody wrote it down, and from there the project goes one of three ways. The vendor does the work for free and loses money. They come back for more budget mid project. Or they skip it, and a year later you are trying to hand over a product with no documentation and no environments. The third way is the most common one.

Look at what the hardest line actually costs

In that marketplace quote the sharpest risk sat in one item: a payment integration bundled with multi vendor support, at an hour count that covers a fraction of the work.

Find the most technical line in the document and look at the hours next to it. If exchanging data with somebody else’s system is priced below the page markup, the quote was written without opening that system’s documentation. This happens more often than you would think. Checking takes a minute.

Ranges get drawn more often than calculated

A good quote gives three numbers: minimum, expected, maximum. A bad one gives exactly the same three, so look at how they were produced. The tell is that every scenario differs by the same coefficient, which spreads uncertainty evenly while in reality it sits in two or three specific blocks. In a genuine estimate the markup stays almost still between scenarios and the integration doubles. Worse is when the base estimate is already optimistic, because then the whole range including the pessimistic case sits below a realistic expectation, and the document looks cautious while leaving no slack at all.

A below market rate ends up hurting you

Ask plainly whether the rate is cost or sale price. Understated hours and an understated rate compound, and if a vendor quotes noticeably below the market rate for the seniority you need, their cost eats almost the entire price.

For a client that feels like a discount right up to the middle of the project. After that the team either leaves or starts economising on what you cannot see, which means testing and architecture. Verifying that takes another vendor. It costs more than the difference in the quote, and people usually order it after something has already broken.

The schedule is built from the calendar, not from people

If the plan assumes a developer produces a full calendar month of useful hours, it will slip. Real output is lower, and I wrote about why in the article on MVP estimates.

We walked into this ourselves while estimating an education platform. The first version was built from market rates and produced a multi million rouble range. After correcting for the team’s real capacity it became clear the full scope was months of work for one person, and the choice came down to three options: cut scope, extend the timeline, decline. Saying that before the start is unpleasant. Saying it in month three is worse. Much worse.

Ask who owns the product after delivery

Delivery is not the end. Servers, domains, certificates, updates, monitoring and fixes remain, and if the quote says nothing about them, after launch nobody is doing that work. While you are at it, ask whose accounts will hold the domain, hosting and repository. The correct answer is yours. From day one. If the vendor hesitates here, you have learned more about them than the rest of the quote can tell you.

What to ask when there is no time for a full review

Ask for a breakdown by blocks of work, the list of assumptions behind the numbers, and an explanation of how the minimum and maximum were derived. A quote that cannot be taken apart cannot be verified by anything except trust in its author. What you are checking is the composition behind the figure.

People often ask: what if there is only one vendor and no choice? Then those three questions work as insurance. The answers show what the person knows about your project and what they do not, and at least you will know where it is likely to break.

What I cannot tell you is how many quotes on the market are understated on average. We only see the ones clients bring for review, and they bring them when something already feels off. That sample is bent. Conclusions about the whole market do not follow from it.

A vendor with a complete estimate has an awkward property: they always look more expensive than the one with an incomplete estimate. The cheap proposal wins the tender, the expensive one survives to delivery, and the difference between them is usually whether somebody counted the integrations. If you want a second opinion on yours, send it over and say which line bothers you most.