Estimates, budgets and vendor selection

Money conversations in software break at the same point every time: the client wants a number, the vendor says «it depends», and both sides get frustrated. Both are right. The number does depend, not on abstract complexity but on specific things that can be listed and checked.

Collected here is what we use ourselves: three point estimates instead of a single number, the blocks of work that go missing from cheap quotes, planning from real developer output rather than the 160 hours a calendar month suggests, and the spike as a way to test the main technical risk before the full budget is discussed.

All of it has been tested on our own projects and on quotes clients brought to us for review. In one of those the scope was understated roughly threefold, and even the vendor's pessimistic scenario sat below our trimmed optimistic one. The review took an hour and saved the client months.

September 18, 2026 How to review a software estimate: six signs the quote is understated A quote is judged by its structure, not its total: does it have a breakdown by blocks, a list of assumptions, and a three point estimate. Six signs of an understated quote: missing blocks of work, a heavy integration squeezed into one line, a cosmetic range, a below market rate, a schedule built on 160 hours per month, and no line for what happens after launch. September 18, 2026 MVP development cost in 2026: how an honest estimate is built An honest MVP quote is a range built from blocks of work, not a single number. The spread inside that range comes from integrations, whether design already exists, and how many blocks the vendor forgot to count. A quote you cannot take apart cannot be verified by anything except trust. September 18, 2026 Technical spike: testing the main project risk in a few days A spike is a small paid step that tests the main technical risk rather than a feature: can we connect to the system, is the data readable, can the document be produced, can the result be exported. It runs for a few days, is priced at the lower bound, and ends on a written completion criterion rather than a feeling that things are now clear. September 18, 2026 How to write a development brief that gets you a range instead of «it depends» To get a range on the first call, a brief needs five things: the problem in measurable form, a user scenario, the list of external systems, a deadline with a reason, and a budget frame. You do not need to write a technical specification, that is the vendor's job.

FAQ

Where do I start if I only need a ballpark

With the format and the list of external systems. The format sets the order of magnitude, the integrations decide where inside the range you land. Those two inputs are enough for a range without a full discovery.

Why do vendors differ by several times on the same brief

Usually because they are pricing different scopes. One quote includes discovery, infrastructure and stabilisation, another covers screens only. Compare the list of work rather than the totals.

What if a vendor refuses to break the number down

Treat that as a signal in itself. A quote that cannot be taken apart cannot be verified, and it also cannot be trimmed in a meaningful way when the budget is short.

← All articles