Software Estimates: Why They're Ranges and How to Read One

An estimate arrives, and it reads like a promise: €18,000, ten weeks. Clients then compare quotes the only way the format allows, by picking the smallest number. That comparison rewards the studio that guessed wrong most confidently. A real estimate is a statement about uncertainty, and if nobody wrote the uncertainty down, the number is decoration.

Why honest estimates are ranges

Nobody knows what software will cost before it's built. What a studio can know, from similar projects, is the spread: "this piece takes 20 to 35 hours depending on what we find in your existing code." A range carries information a single number destroys. If a quote says 30 hours flat, it's claiming that scope, environment, and feedback speed are all certain, and none of them are.

The width of the range is the useful part. Rebuilding a well-understood CRUD module: narrow. Replacing a system whose rules exist only in one employee's head: wide, and no estimator can shrink it honestly without reading that code or documenting that process.

What actually moves a project past the estimate

We track the reasons real projects drift, and they're rarely about code:

Scope that changed shape. Not "feature creep" in the blame sense. A client discovers, mid-project, what they actually need, because building is how they found out. Budgeted change order, fine. Silent expansion, not fine.
The codebase nobody described. "Just add a field" meets a legacy schema with triggers, and a two-hour task becomes two days of archaeology.
Decision latency. A week waiting for content, a design sign-off, a legal answer. The estimate covers work, not waiting, and the calendar fills anyway.
Integrations that behave differently than documented. Every third-party API is documented by its marketing department.

Notice that three of the four are client-side factors. That's not finger-pointing; it means the estimate is a two-sided deal. The studio can commit to its side, hours spent building; the client needs to commit to theirs, decisions and materials on time.

What a good estimate looks like

Written down, line by line, with the assumptions attached:

Checkout flow rework
  Cart and totals recalculation        12–18 h
  Payment provider handoff             8–12 h
  Order confirmation emails            3–5 h
  Staging deploy and testing pass      4–6 h
Assumptions:
  - Stripe stays the payment provider
  - Current checkout tests keep passing
  - Content and product data arrive by week 2
Not included: new customer accounts, marketing emails

The assumptions section is the part most quotes leave out, and it's the part that settles 90% of future disagreements. If an assumption turns out to be false ("actually we also need PayPal"), that's a conversation with a price tag, not a fight about whether the estimate was "wrong". The estimate wasn't wrong. The assumptions changed.

How to compare two quotes

Same questions for both studios:

Is this a range, and what's inside versus outside it?
What's listed in the assumptions and exclusions? A quote with exclusions is honest. A quote without them assumes infinite scope.
Who supplies what? Content, hosting, test accounts, API credentials. Client-supplied items are the most common source of calendar slip.
What happens when an assumption breaks? A studio that answers with a process (written change order, re-planned scope) has run projects before. A studio that answers "don't worry" is a quote you'll be renegotiating at hour 40.

Don't compare totals before comparing assumptions. The €14,000 quote with written assumptions and a named exclusions list is often the cheaper project by the end, because the €11,000 one excluded everything that will actually happen.

Keeping the estimate honest during the build

Tracking hours against the estimate isn't bureaucracy, it's the early-warning system. The pattern to watch: at 70% of the budgeted hours, roughly 70% of the work should be done. If a report says 70% of hours are gone and the build is 40% done, the conversation needs to happen right then, while there are good options left: cut scope, extend budget, or accept less polish. The same conversation at 120% is just an apology.

And when the project finishes inside the range, the estimate did its job. When it doesn't, the record of hours and assumptions shows why, and that record is what turns your next estimate from a guess into a measurement.