How we estimate (badly, on purpose)
Our estimates are off by 18%, and that's the point.
by Thanos K.
We estimate in weeks, never hours. We estimate ranges, never points. We add 20% on top of whatever we genuinely believe, and then we tell the client about the 20%. Our estimates have been wrong, on average, by 18%. That's closer than any honest estimate we've ever seen another studio publish.
The trick isn't a better algorithm. It's caring about being wrong. Most studios pad their estimates secretly — a three-week project becomes a four-week quote, and nobody discusses the extra week. We pad them out loud. Same number, different conversation. The client knows what's buffer and what's work.
When we're way off, we say so on Friday. Not at the end of the project, not in a steering meeting, not buried in a status doc on page four. Friday note, week four: "this is going to take three more weeks than we thought; here's why." Twice in two years we've shipped early. More often we're right. Occasionally we're very wrong, and the client hears about it the same week we figure it out.
The reason this works is that nobody is surprised. Surprise is the part of slippage that destroys trust — not the slippage itself. Clients accept that software is hard. They don't accept being told everything is fine until it isn't.
Above: every estimate from the last projects, plotted against how long the work actually took. The center of mass sits at +18%. The long tail to the right is the projects where we were wrong by half a quarter — almost always because the spec changed in week two and we didn't re-estimate aloud. The thin left tail is the two projects we shipped early. We talk about both kinds of misses in our own retros, with names attached.
What we don't estimate: anything where the answer would be a number we made up. "How long until the integration with the third-party API?" is a fake question if we haven't touched the API yet. The honest answer is "a week to spike it, then we'll tell you." Clients flinch at first. They're used to studios that fake confidence. By week six they're relieved.
One thing that changed our hit rate: writing the estimate down with a paragraph next to it. Not just "four weeks" but "four weeks, assuming the staging environment is up by week two and we don't need to migrate the legacy users." The paragraph is the contract. When week three brings news that the legacy users are migrating after all, we're re-quoting from a stated assumption, not from a vibe.