PROCESS·FIELD NOTES·6 MIN READ

{{ shareLabel }} Print {{ saveLabel }}

We used to estimate in hours. Every developer does at some point — it feels precise, it feels accountable, and clients can multiply the hours by a rate and know what they're paying for. The problem is that software estimates measured in hours are almost always wrong, and the wrongness accumulates in one direction: over budget, over time, over the threshold of what the client expected when they signed.

The planning fallacy — the well-documented human tendency to underestimate how long things take while accurately predicting the timelines of others — is not news. What's less appreciated is that software has a compounding version of this problem. We don't just underestimate the tasks we've identified. We systematically fail to account for the tasks we haven't thought of yet. Hofstadter's Law captured this recursively: it always takes longer than you expect, even when you take into account Hofstadter's Law.

The solution is not better estimating. We tried that. The solution is a different kind of agreement between the builder and the client — one that doesn't require the builder to predict the future with precision they don't have.

What hour estimates actually measure

A developer's hour estimate measures how long they think it would take to write the code if everything goes perfectly and nothing unexpected happens. It doesn't include: time to fully understand the requirement including the clarifying questions not yet asked; the debugging session caused by a dependency that behaves differently in production than in development; time to write tests, review code, and respond to feedback; time spent waiting for decisions, system access, or stakeholder answers; or the scope clarifications that arrive after work has already started.

Add those up across a multi-week project and you're looking at a 40–60% undercount as a baseline before anything actually goes wrong. The estimate isn't a lie — it's an answer to a question that was never actually asked.

The incentive problem nobody names

Hour-based billing creates a specific structural misalignment that's worth naming directly. When a builder is paid for time, a longer project is a more profitable project. That's not a moral failing — it's arithmetic. Even the most principled hourly shop has to fight against the incentive to let things run long, to revisit finished work, to gold-plate features that didn't need it.

"Fixed-price inverts this. When the price is set, the builder's margin depends on delivery efficiency. Fast, clean, accurate delivery is directly in the builder's financial interest."

The client's incentive shifts too. Under hourly billing, clients hold back requests ("this might be expensive to add") or rush decisions ("the meter is running"). Under fixed-price, both of those pressures disappear. The client can focus on whether the software is right, not on whether asking another question will cost them money.

What we do instead

We scope every project in outcomes, not hours. A scope document describes what the software does when it's finished — the user flows, the data it manages, the integrations it connects to, the performance bar it meets. From that scope we derive a fixed price and a delivery window. If the scope changes materially, we price the change through a lightweight change-order process.

The scope is a collaborative document, not a spec handed over a wall. We produce it in the first week of every engagement — during a paid discovery — because discovery almost always changes what the scope needs to be. Clients often come in with a feature request and leave with a clearer understanding of the actual problem and a simpler, more focused solution.

The other piece is reference class forecasting: instead of estimating the current project from scratch, we compare it to similar projects we've already delivered. A six-page web app with two integrations, we've done those. A mobile app with offline sync, same. The estimate comes from history, not from summing imagined hours — and history is a more reliable predictor than optimism.

The number that actually matters

What clients need is not hours. It's two numbers: how much will this cost, and when will it be done? Hours are a proxy for the first number that introduces more uncertainty than it removes. A fixed scope with a fixed price answers the question clients are actually asking — and puts both sides of the table on the same side of the problem.