#founders
#product
#software-development
Research

The estimate that wins the deal is the one that slips the most

Every software quote that promises an exact date is selling, not estimating. I have lost deals for quoting the honest number and watched the cheap one arrive later and half-built. Why the lowest timeline is usually the one that slips most, and what to check before you sign.

Por Victhor Araújo

Founder of Revin. Engineer by training, specialist in software development and digital products.

Every software proposal that promises an exact date is selling you something. Not always lying, but selling. The exact date is the line in the document written to get your signature, not to be met.

I say that as someone who writes those proposals. I have lost deals for quoting a bigger number than the competition, and early on I signed off on timelines I knew were optimistic just to stay in the running. I learned to read estimates with suspicion because I have stood on both sides of the table.

If you are the founder lining up three quotes in a spreadsheet, leaning toward the cheapest and fastest, this is about what that number hides.

Why the lowest number almost always wins

The dynamic is simple and a little rigged. You ask three vendors for a quote. One says six months, another four, the third three. With no technical way to judge who is right, you are left with the two criteria that are easiest to compare: price and time. The lowest wins.

But the lowest number is rarely the most honest. It is the most optimistic, or the one most desperate to close. A short estimate is not a sign of a sharper team; usually it just assumes everything goes right: no bugs, no rework, none of the requirements nobody mentioned during the sales call. Software never goes entirely right.

Last year we lost a scheduling system for a chain of clinics over exactly this. We quoted five months; a competitor promised two and a half at half the price. The founder took the two and a half, of course. I ran into him at a conference about seven months later. The system had just gone live, with half the screens we had scoped, and the vendor was already asking for a change order. He paid more than our five months would have cost, and shipped later. I do not tell this to sound clairvoyant. The sample is biased; I only hear about the ones that went wrong and came back to talk. But I see the pattern often enough that it stopped surprising me.

A few of the projects we picked up after an optimistic timeline blew up are at revin.com.br/en/cases, now with product in production instead of a change order on the table.

The date you circled on the calendar when you signed is rarely the date the product actually ships.

The date you circled on the calendar when you signed is rarely the date the product actually ships.

The ninety-ninety rule

There is an old engineering joke, usually credited to Tom Cargill at Bell Labs, that captures it better than any chart: the first 90% of the code takes 90% of the time, and the remaining 10% takes the other 90% of the time. Add it up, you get 180%. It is a joke, but everyone who has ever shipped software laughs a little sideways, because that is exactly how the math lands.

The reason is that the visible part of the work, the part you can demo on a nice screen, is the part that moves fast. What drags is everything else, the stuff nobody puts in the quote because it does not show up in a demo:

  • The error paths: what happens when the payment fails, when the connection drops mid-request, when the user does the thing you swore nobody would do.
  • The migration of the old data, which is always dirtier than the client admitted during the sale.
  • The hardening for production: performance under load, permissions, logging, the behavior at peak that the developer’s laptop never saw.

Across a rough count of the projects we have inherited half-finished, that final 10% ate something close to 40% of the total effort. I hold that number loosely: small sample, and all of them arrived sick, so it is probably inflated. Either way the direction never changes. The end costs far more than the middle seems to promise.

On paper the plan looks whole. The little boxes nobody drew are exactly the ones that hold up the delivery.

On paper the plan looks whole. The little boxes nobody drew are exactly the ones that hold up the delivery.

An estimate is not a fixed date

The fix is not to estimate so well you nail the date. Nobody nails the date. The fix is to stop treating an estimate as a promise and start treating it as a range. When a client asks me when it will be done, the honest answer has three numbers, not one: the good case, the likely case, the bad one. If the gap between good and bad is huge, that gap is measuring the size of what we still do not know about the problem, and hiding it behind a single number is the dishonest move.

What we do to shrink that gap is slice the work into pieces that run. Instead of disappearing for three months and coming back with "the product", we ship something demonstrable every week: small, sometimes ugly, but standing and testable by real people. The number you can trust is always the one attached to something you have already watched work. The rest is a guess wearing the costume of a commitment.

When we come into a project through a Diagnostic Sprint, a good chunk of the first conversations is recalibrating an estimate someone sold short: separating surface mess from an actual hole in the schedule.

When a tight deadline is honest

Let me be fair, or this turns into an excuse for every slip. Not every tight deadline is a lie. Some dates the world imposes on you: the regulation that takes effect, the round that closes, the industry conference that will not move to next month because your backend is late. There, a short timeline is a real constraint that came from outside, and a good team works inside it by cutting scope out in the open, without quietly cutting tests.

The difference between the two is what disappears when things get tight. An honest deadline trims the feature list and tells you. A sold deadline trims the quality and stays quiet. You only find out which one you bought once it is in production.

The honest quote costs more on paper

In the end, the founder’s choice is not between expensive and cheap. It is between paying the difference at signing or paying it later, with the interest of change orders, rework, and a product that arrives late and half-built. The honest quote almost always looks like the worse deal in the moment you decide. It is usually the only one that still respects your cash twelve months on.

If you have three quotes on the table and the cheapest one looks too good to be true, half an hour with someone who has watched this movie from both sides is worth it before you sign.

Ready to elevate your business

Schedule a meeting
Share
Link de compartilhamento LinkedinLink de compartilhamento XLink de compartilhamento WhatsappLink de compartilhamento Facebook
You may also like

Every two weeks. The technical decisions we made, and what we learned.