How to Read a Technical Estimate (And Why It's Always Wrong)

You asked how long it would take and you got a number. “Eight weeks. Forty thousand.” It felt good to hear. Finally, something concrete you can put in a plan and repeat to your investors.

Here’s the hard truth a technical co-founder would tell you over a beer: that number is wrong. Not because the person quoting it is dishonest, though they might be. It’s wrong because every software estimate is wrong, and the confident ones are the most wrong of all. The useful skill isn’t finding the accurate number. It doesn’t exist yet. The skill is reading what the estimate is actually telling you about risk, and knowing which questions to ask before you sign anything.

Why the Number Is Always Wrong

Building software isn’t like building a wall. With a wall you know the length, the height, the price of a brick. With software, the estimate is a guess about work that partly doesn’t exist yet, because the act of building it is how you discover what it actually involves.

Three forces guarantee the miss. The first is the cone of uncertainty. At the very start of a project, before a line of code exists, the realistic spread around any estimate runs from roughly a quarter of the guess to four times it. That cone narrows as the work reveals itself, but at the moment you most want a firm number, a firm number is least possible.

The second is the 90/10 rule, and it’s brutal. The first 90 percent of any feature takes about 10 percent of the time. It demos beautifully in week two. Then the last 10 percent, the error handling, the edge cases, the moment two systems have to actually talk to each other, eats the remaining 90 percent of the schedule. The part you can see is fast. The part you can’t is where the calendar goes to die.

The third is unknown unknowns. Not the risks the team flagged, but the ones nobody knew to look for. The payment provider that behaves differently in production. The “simple” integration whose documentation is a polite work of fiction. You cannot estimate what you don’t know exists, and there is always something you don’t know exists.

Padding and Sandbagging: Both Are Happening

Once you accept the number is a guess, the next question is which way it’s been bent, because it has been bent.

Padding is when a team inflates the estimate to protect themselves. Sometimes that’s prudent, a buffer against the unknowns above. Sometimes it’s a cushion because they don’t trust their own understanding of the work, and the padding is hiding a lack of clarity you’d want to know about.

Sandbagging is the opposite and more dangerous to you. A low, confident number that wins the deal, quoted by someone who either hasn’t thought hard about the risks or has, and is betting you’ll be too committed to walk away when the real cost surfaces in month three. The suspiciously cheap quote isn’t a gift. It’s a number set to win a signature, with the truth deferred until it’s expensive for you to leave.

Neither padding nor sandbagging is visible in the headline figure. Both look like “eight weeks, forty thousand.” The only way to tell them apart is to read what sits underneath the number, which is exactly what a bad estimate is built to leave out.

What a Real Estimate Actually Contains

A good estimate shows its working. It reads less like a price tag and more like a conversation someone started with themselves about everything that could go sideways. Four things separate the real thing from a sales number.

Stated assumptions. “This assumes you already have the designs. This assumes one payment provider, not three. This assumes we’re not migrating your existing data.” Every assumption is a place the number changes if reality disagrees. A team that writes them down is telling you where the edges of the quote are.

Flagged risks. The honest estimate names the parts the team is least sure about. “The reporting engine is the risk here. We haven’t built against this API before.” That sentence is worth more than the whole rest of the document, because it points at exactly where the schedule is most likely to move.

A range, not a point. “Six to ten weeks” is a more truthful statement than “eight weeks”, because it admits the cone exists. A single confident number pretends to a precision that the work doesn’t support yet.

What is explicitly not included. The best estimates have a section titled something like “out of scope.” No admin panel. No email deliverability tuning. No load testing. This list prevents the argument you’d otherwise have in month two about whether that thing was “obviously” part of the deal.

The Single Confident Number Is the Reddest Flag

It feels like the opposite. Confidence reads as competence. But an experienced engineer knows how wrong estimates run, and that knowledge makes them careful, not bold. The person who says “eight weeks” without a flicker of doubt is telling you one of two things: they haven’t thought hard enough to find the risks, or they’ve found them and decided you don’t need to know. Neither is what you’re paying for.

The right response to a confident number isn’t to feel reassured. It’s to get curious. Where are the assumptions? What’s the riskiest part? What’s not included? A good team will happily answer, because they’ve already asked themselves. A team that gets defensive or vague just told you the confidence was for sale.

Here is one of ours, because this cuts both ways. On a fitness-platform rebuild I estimated two to three months, because that is what a job like that usually takes us. Around the two-month mark, as we got deeper into it, we understood we were nowhere near. Some of it was genuinely harder than it looked. Some of it was our own internal misunderstanding about what needed to happen. The honest number was another six months. After a couple of sleepless nights I did the only thing that works: I sat the founders down and told them exactly what we had got wrong, what it meant technically, and why it would take longer. They were refreshingly practical. We agreed what we could realistically ship in the original window and moved the rest to after the launch. The estimate was wrong. Hiding that would have been the actual mistake.

Ask the Better Question, Then Do the Buffer Math

Stop asking “how long will it take.” You already know the answer is a guess. Ask instead: “What are you least sure about, and what happens to the timeline if that goes wrong?” The first question invites a comforting lie. The second invites the truth, and how a team answers it tells you almost everything about whether you can trust them with your money.

Then protect yourself with arithmetic, not optimism. Take the optimistic end of whatever you’ve been quoted and roughly double it for planning. If they said eight weeks and forty thousand, plan your runway around sixteen weeks and a number closer to seventy. This isn’t cynicism and it isn’t an insult to the team. It’s just where the cone of uncertainty actually sits at the start of a project.

An estimate, read properly, isn’t a promise you hold someone to. It’s the opening move in a conversation about risk: what we know, what we’re guessing, what could go wrong, and what we’ll do when it does. The teams worth working with treat it exactly that way, and so should you. When we quote at Hurricane, we quote in ranges with the risks written down, because a number that hides its own uncertainty isn’t doing you a favour. It’s just setting up the fight you’ll have later.

If you’ve got a quote sitting in front of you right now and you can’t tell which kind it is, that’s exactly the read we do for founders before they sign. No pitch, just an honest look at what the number is hiding.

The test is simple enough to run on any quote you’re handed: does it show its work, or does it just show you a number and ask you to trust it? Trust the one that shows its work.