The last three estimates you approved came in at two to three times the number you signed off on. "Six weeks" became four months. "Just an MVP" became two quarters and a follow-on contract. At this point a quote lands on your desk and you reflexively double it, then add 50%, then still feel like you're being optimistic. You've stopped trusting estimates entirely, which is its own problem — because now you can't tell the difference between a team that's lowballing you and a team that's telling you the truth.
That's the real cost. Not that estimates are wrong — they're always somewhat wrong, that's the nature of the thing. The cost is that once you stop trusting any of them, you lose the ability to plan, to compare vendors, and to call out the firms that are buying your business with a number they have no intention of hitting.
What a blown estimate actually costs
A doubled timeline isn't just a doubled timeline. It cascades.
You raised money against a roadmap. The product was supposed to ship in Q2, which meant the enterprise pilot started in Q3, which meant revenue in Q4, which meant you'd raise the next round from a position of strength. The estimate slips to 2x and the whole chain moves: pilot in Q1 next year, revenue you were counting on doesn't land, and now you're raising a bridge at a flat valuation instead of an up-round off traction. The engineering delay cost you the financing strategy.
Put a number on the direct burn alone. A six-person team at $15k per engineer-month that runs four extra months past a six-week estimate has spent an unplanned $360k. But the direct cost is the small one. The expensive part is the opportunity cost — the market window you missed, the customer who went with a competitor who shipped, the round you raised at worse terms because the proof point was late.
And here's the asymmetry that makes lowballing so dangerous: the firm that quoted you "six weeks" to win the deal pays nothing when it's wrong. You pay all of it. So the incentive, unless you know how to read the estimate, runs entirely against you.
Why estimation fails — and it's not laziness
Software estimation is genuinely hard, for reasons that are structural, not character flaws. Understanding them is how you tell a hard-but-honest estimate from a fantasy.
Unknown unknowns. When you estimate building a house, you know the steps — foundation, frame, roof — because houses have been built a million times. Custom software is closer to research: you're building something that didn't exist, which means some of the work is discovering what the work is. You cannot estimate the time to solve a problem you haven't yet understood, and a meaningful fraction of every real project is exactly that.
The cone of uncertainty. At the start of a project, before anyone's written a line, the honest error bar is enormous — a "six week" task could credibly be three weeks or fifteen. As the team builds and learns, the cone narrows. By the time it's half done the estimate for the rest is tight. The problem is that the moment you most want a precise number — the start — is the moment the cone is widest. A single point estimate at the start of a project is a lie by construction. The truth is a range, and the range is wide.
Scope creep, mostly invisible. "Can it also do X" arrives in a Slack message, not a change order. Each one is small. Twenty of them double the project. Nobody decided to double the project; it accreted, one reasonable request at a time, and the original estimate was for a product that no longer exists.
Integration surprises. The estimate covered the code your team writes. It didn't cover the third-party API that's undocumented, rate-limited, and returns a different shape on Tuesdays. It didn't cover the legacy system you have to integrate with that nobody fully understands. Integration is where estimates go to die, because it's where you depend on things you don't control and can't inspect until you're in them.
None of these are fixable. They're the physics of the work. What separates a serious team is not that they've eliminated uncertainty — it's that they estimate honestly in the presence of it.
How serious teams estimate
A team that knows what it's doing doesn't hand you a single number with false confidence. They do four things.
They quote ranges, and the range is informative. Not "six weeks" but "six to ten weeks, and here's what determines where in that range it lands." The width of the range tells you how much uncertainty they're carrying. A narrow range on a vague spec is a red flag — they either don't understand the problem or they're hiding the risk to win the deal.
They spike the unknowns before quoting the project. When there's a genuinely uncertain piece — the gnarly integration, the novel algorithm, the performance requirement nobody's hit before — a serious team proposes a short, paid spike: a few days to build a throwaway proof and collapse the uncertainty before committing to a number for the whole thing. A team that quotes a hard integration confidently without ever having touched it is guessing, and charging you for the guess.
// honest sequence
spike → 3 days, de-risk the payment-rails integration
estimate → now the range is 6-8 weeks instead of 4-16
build → milestones every 2 weeks, re-estimate the cone as it narrows
They estimate to milestones, not to a finish line. "It's done in four months" is unverifiable until month four, when it's too late. "Auth and data model in two weeks, first vertical slice in week four, integration proven by week six" gives you checkpoints. Each milestone either lands on time or it doesn't, and a missed milestone in week two is a cheap early warning, not a catastrophic month-four surprise.
They re-estimate as the cone narrows. A good team treats the estimate as a living number that gets more precise as they learn, and they tell you when it moves and why. A team that quotes once and never updates until the deadline blows past is managing your expectations, not the project.
How to read an estimate
You don't need to be technical to spot an honest estimate. You need to ask four questions.
"What's the range, and what drives it?" A single number is a warning. A range with named drivers — "wider if the legacy integration is as undocumented as we suspect" — is a team that's thought about what could go wrong.
"What's the riskiest part, and how will you de-risk it early?" If they can name the scariest piece and have a plan to test it in week one, they understand the project. If everything is "straightforward," they haven't looked hard enough or they're managing you.
"What are the milestones in the first month?" Concrete, checkable deliverables in the first few weeks mean you'll know early if things are slipping. No near-term checkpoints means you find out at the deadline.
"What's explicitly out of scope?" An honest estimate has a boundary. A team that lists what they're not building is a team that's thought about scope creep. A team that says "we'll handle whatever comes up" is a team that's already lost the scope battle.
The failure mode of the wrong read: you pick the lowest number, because lowest looks like best value. The lowest number is almost always the one with the most hidden risk — the team either doesn't understand the project or is buying the deal. You don't save money. You just relocate the overrun from the proposal to the invoice, where it's bigger and you have less room to push back.
What fixed looks like
Fixed is an estimate you can plan against. It's a range with named drivers, the riskiest piece spiked before anyone commits to the whole number, milestones every couple of weeks that tell you early if the cone isn't collapsing the way it should, and a re-estimate every time the team learns something that moves the number.
Fixed is a scope boundary written down, so "can it also do X" is a conversation about the timeline rather than a silent tax on it.
Fixed is you, the founder, able to look at two proposals and know which one is honest — not because one number is lower, but because one team showed you their uncertainty and a plan to shrink it, and the other handed you a confident single number for a problem they've never solved.
The goal was never a perfect estimate. Those don't exist. The goal is an honest one, and the ability to tell it apart from a hopeful one before you sign.
This is for you if
You're a founder who's been burned by estimates that doubled, and you need either a project scoped and estimated by people who'll tell you the truth, or a second opinion on a proposal that feels too good to be true.
A scoped estimation engagement — we break down the project, spike the genuinely risky pieces, and hand you a ranged estimate with milestones and a scope boundary — starts at $25k+. A full build with milestone-based delivery and live re-estimation as the cone narrows runs $50k+, $100k+ for larger systems where the integration and scale risk is substantial enough to need real de-risking up front.
This is not for you if you want someone to validate the lowest bid you've already received — that's the bid most likely to blow up, and we're not going to tell you otherwise. It's not for you if your spec is genuinely fixed and trivial, in which case any competent shop's estimate will do. It's for the founder who's stopped trusting estimates, can't tell lowballing from honesty anymore, and is about to sign another "six weeks" that everyone in the room quietly knows is four months.