Software development estimation: how to read the number

Your developer sent back a number. Here are the four questions that turn it back into the range it actually is.

The email was four lines long. A greeting, a thank-you for the call, then the number: 12 weeks, $180,000. The founder forwarded it to us with one question attached. “Is this good?”

Software development estimation is the practice of predicting how much time and money it will take to build a piece of software. What actually lands in your inbox, though, is not a prediction. It’s a range that somebody collapsed into a single number, because a single number is what you asked for. Everything useful lives in the range they threw away.

The founder in question, a former hospital operations director building a scheduling product for private clinics, could not read that number. Most of the people we work with can’t either, and it isn’t a failure of intelligence. It’s that every guide ever written about software development estimation is written for the person producing the estimate. Search the term and you’ll find nine articles teaching engineers how to size a task and none teaching a CEO which questions make the number honest.

This is the other kind of article.

What a software development estimate actually is

Three different objects get called “an estimate,” and confusing them is where most of the money dies.

There’s the guess, offered on a call by someone who has known your problem for forty minutes. There’s the budget, produced after a team has read your requirements and argued about them. And there’s the promise, the number a vendor will be held to and will therefore defend in every conversation you have for the next six months.

They arrive in the same font. They mean completely different things.

Underneath all three sits the same machinery: someone breaks the work into pieces, sizes each piece, and adds them up. The sizing might be in days, or in story points, or in t-shirt sizes. The unit doesn’t matter much to you. What matters is that every one of those pieces was sized under uncertainty, and the uncertainty didn’t survive the addition.

Why software development estimation always produces a range, and why the range is hidden

Steve McConnell spent a career measuring how wrong software estimates are, and the result has a name: the Cone of Uncertainty. Early in a project, at the point where you’ve agreed on a concept but not on the details, estimates made by skilled estimators can be off by a factor of four on the high side and a factor of four on the low side. That’s a sixteenfold spread between the pessimistic and optimistic ends. Not because the estimator is bad. Because the project isn’t decided yet.

The cone narrows as the project goes on, and most of that narrowing happens in the first 20 to 30% of the calendar. But here’s the part founders consistently get wrong: it doesn’t narrow because the team tries harder. It narrows because decisions get made. Variability in the estimate is a direct reflection of variability in the project itself. As McConnell puts it, “It isn’t possible to be more accurate; it’s only possible to be more lucky.”

Which produces the single most useful sentence here:

You cannot negotiate an estimate down. You can only decide fewer things for it to be uncertain about.

Every founder who has ever pushed back on a quote has felt the vendor “sharpen the pencil” and come back 15% lower. Nothing was learned in between. No decision was made. The uncertainty didn’t go anywhere. It just got reassigned, quietly, from the vendor’s margin to your launch date.

What are the four types of estimates?

Most articles will sort estimates by technique: analogous, parametric, three-point, bottom-up. That taxonomy is for the estimator. Here’s the one that’s for you, sorted by what the number actually commits you to.

The ballpark. A shape, not a number. Offered from experience before anyone has read anything. Its only honest job is to answer “should we even be having this conversation?” Carrying the full sixteenfold spread, it is worthless for planning and dangerous in a board deck.

The budget estimate. Produced after a real discovery pass, where someone has interrogated your requirements and found the parts you hadn’t thought about. This is the one you plan against. It should arrive as a range. If it arrives as a point, someone rounded for you.

The commitment. What the team will actually be held to. It is only honest once enough has been decided to narrow the cone, which in practice means after a chunk of the work has begun.

The contract price. A number with legal consequences. It contains a risk premium, and you are paying that premium whether or not the risk fires. This is where the estimate stops being arithmetic and becomes a negotiating position, and it is why the number in a statement of work is never the number from the first call.

These are not four techniques. They are four levels of promise. The fatal move, and we watch founders make it constantly, is treating a ballpark as if it were a contract price, then feeling betrayed when reality shows up.

The four questions that pull the range back out

When a number arrives, you have a short window in which asking hard questions is still normal and not yet adversarial. Use it. These four questions do more work than any amount of haggling.

1. “What’s the worst case, and what has to go wrong to get there?”

The best estimators already track this. Jacob Kaplan-Moss, who co-created Django and has written the clearest practitioner guide to capturing uncertainty alongside time, argues that any estimate worth anything carries both. “Ten to fifteen days” tells you something that “ten days” actively hides.

If your vendor can’t produce a worst case, they haven’t thought about it, and you have just learned something expensive for free.

2. “Which single line are you least sure about?”

Variance is almost never spread evenly across a project. It concentrates. One task, usually the one nobody has done before, accounts for most of the spread in the whole plan. Find that task and you’ve found your actual risk, along with the only place where spending money early has real returns.

For the clinic scheduler, it was never the booking calendar. It was the insurance eligibility check, an integration with a system whose documentation was a PDF from 2016.

3. “What did you assume I’d have ready, and by when?”

Buried in every estimate is a set of assumptions about you. That you’ll approve designs in two days rather than two weeks. That you’ll get the credentials from your payments provider. That you’ll decide the pricing model before the billing screens get built. That you’ll find a real clinic willing to test with real patients.

In our experience the most common cause of a missed date is not the engineering. It’s a founder who is also running sales, fundraising, and hiring, and who is now the bottleneck on eleven decisions nobody told them they owned.

4. “What is not in this number?”

Ask it plainly. Data migration from the spreadsheet everyone still uses. Admin tooling for the ops team. The second round of design revisions. Load testing. App store review. Two weeks of bug fixing after launch, which is not optional and never appears in the estimate.

Anything unstated becomes a change request later, at a price nobody negotiated under competitive pressure.

What is the 80/20 rule in software development?

People search for this, so let’s answer it, and then correct it.

The version engineers actually tell each other is Tom Cargill’s, from Bell Labs, and it’s funnier and truer: the first 90% of the code takes 90% of the time, and the remaining 10% of the code takes the other 90% of the time.

It’s a joke about a real phenomenon. Software gets to looking finished long before it is finished. The demo in week six is beautiful. It moves, it clicks, it makes your board lean forward. What it doesn’t do is handle two receptionists sharing one login and double-booking the same 3pm slot. Or a failed card payment. Or a patient who cancels twice and gets billed anyway. Or the thirty tedious states between “happy path” and “production.”

That gap between demo and done is where estimates go to die, and it’s why a vendor who shows you something impressive in week six and then goes quiet is not necessarily behind. They may have just reached the real work.

How to estimate software development cost when you’re the one paying

You don’t forecast it. You bound it. Three moves, in order of how much they’re worth.

Buy a decision, not a discount. If one line item carries most of the uncertainty, pay for a short time-boxed investigation of exactly that thing before committing to the whole build. A paid two-week spike on the insurance integration is dramatically cheaper than the risk premium you’d otherwise pay on a twelve-week fixed price, and cheaper still than discovering the problem in week nine.

Budget the worst case, plan against the expected case. Take the range seriously in both directions. Put the pessimistic number in the model you show your board. Run the company against the expected one. A founder who has already told investors the optimistic number has removed their own ability to make good decisions later.

Understand what the pricing model does to the room. A fixed price buys you certainty and you pay for it twice: once in the risk premium baked into the number, and again in a partner who now makes money every time they say no to you. Time and materials is usually cheaper in total and requires you to actually pay attention. Neither is right in the abstract. We’ve written separately about what drives the price of an app, and the short version is that the biggest variable was never the hourly rate.

When the number is bigger than the budget

Almost every founder’s first instinct is to push on the number. It’s the wrong lever, and it’s the one most likely to produce a vendor who says yes and a project that quietly rots.

Push on the decisions instead. Every hour of uncertainty in the estimate is attached to something nobody has decided yet, and you are allowed to decide it. Cut the thing you can’t defend. Defer the integration that serves 8% of users. Ship the version that works for one clinic instead of the version that works for every clinic. Narrowing the project scope is the only move that makes the number smaller without moving the pain somewhere you can’t see it.

The clinic scheduler went from twelve weeks to seven. Not because anyone sharpened a pencil, but because the insurance-billing integration, the single fattest source of uncertainty in the plan, got pulled out of v1 and replaced with a CSV export that a human ran on Fridays. It was ugly. It shipped in time for the flagship customer. The integration was built four months later, properly, by a team that by then knew what the data actually looked like.

The question to ask instead

“Is this good?” is unanswerable, and the founders who ask it are usually hoping someone will absolve them of a decision that is genuinely theirs.

The answerable version is this: what don’t you know yet, and what will it cost me to find out? An estimate that can’t answer that isn’t an estimate. It’s a wish with a decimal point.

Common questions about software development estimation

What is estimation in software development?

It’s the practice of predicting the effort, time and cost required to build software. The output is genuinely a range, because the work hasn’t been fully decided yet. When you receive a single number instead of a range, someone has made a judgment call on your behalf about which end of that range to show you.

How accurate are software estimates?

Early ones are wildly inaccurate, and this is measurable rather than anecdotal. At the concept stage, estimates produced by skilled estimators carry roughly a fourfold error in either direction. Accuracy improves as decisions get made and the scope stops moving, not as the estimator concentrates harder.

How do I estimate software development cost as a non-technical founder?

You don’t. You bound it. Ask for an expected case and a worst case, budget against the worst case, identify the single line item carrying the most uncertainty, and pay for a short, time-boxed investigation of that one thing before committing to the full build.

What should I ask when I receive a software development estimate?

Four things: what the worst case is and what causes it, which line item the team is least confident about, what the estimate assumes you will deliver and by when, and what has been deliberately excluded from the number.

Why do software projects always run over?

Usually not because the engineering was slow. Because the scope kept moving, because decisions the founder owned arrived late, or because work everyone assumed was included (data migration, admin tooling, post-launch bug fixing) was never in the number to begin with.