How we estimate software projects (and why most estimates are wrong)
Every estimate is wrong. The useful ones are wrong in known ways. A practical method we've refined across 50+ engagements — and the failure modes we learned to spot first.
Every software estimate is wrong. The useful estimates are wrong in known directions — early, late, scoped wrong, dependent on a fact you haven't checked yet — and they say so in the estimate itself. The useless estimates pretend to be facts.
Over 50+ engagements we've refined a small set of practices that reliably produce estimates we're proud to sign up to. None of them are clever. All of them are uncomfortable to follow at first.
Estimate at the seam, not at the surface
The natural way to estimate is to read the spec, picture the work, and write down a number. This is wrong because the spec describes the destination, not the road. We estimate at the seam — the boundary between systems that have to talk to each other. Authentication crosses a seam. Reporting that joins two data sources crosses a seam. A button that just writes to your own database does not.
Seams are where estimates rot, because they involve other teams, other timezones, partner APIs, legal review, security review, and at least one person you haven't met yet. List the seams first, estimate them at twice what feels reasonable, then estimate the rest of the work at half what feels reasonable. The total comes out closer to right than either approach alone.
Three numbers, not one
We deliver every estimate as three numbers: a 50% confidence date, an 80% confidence date, and a 'this is when we get worried' date. The 50% number is the marketing date — we say it out loud but commit to it carefully. The 80% number is the contract date — it's what clients build their plans around. The third number is what triggers the conversation about scope reduction.
Three numbers force honesty. A single number always reads as a commitment, even when you intend it as a guess. Three numbers cannot read as a single commitment, so the client and the team can both be honest about what's known and what isn't.
The three-day reality check
Before we sign an estimate over six weeks long, we spend three days building the riskiest single piece of it. Not a prototype, not a spike — a real, deployable slice. If the riskiest piece comes together in three days, the estimate is roughly right. If it doesn't, the estimate is wrong, and we'd rather know that now than at the project's halfway point.
Clients sometimes resist this — three days of paid work feels like overhead. The math is decisive: a three-day reality check has saved us from a multi-month overrun in roughly one in four engagements. The clients who said no to the check have all, without exception, regretted it.
When to refuse to estimate
Some asks are unestimable. 'How long to rebuild our entire platform' is unestimable in any honest way. 'How long to add a checkout flow that matches Shopify's' is unestimable until you've seen the existing code. We've learned to refuse — politely but firmly — when a client wants a number for something that's still a wish.
The right response is to scope the work into something estimable, and then estimate that. 'I can give you a number for the discovery phase that will produce the number you actually want.' This sounds like a hedge. In practice, it's the only honest path. Every client who has accepted this answer has saved themselves a quarter or more.
Want this kind of work on your project?
One conversation, honest pricing, recommended engagement model — within a business day.
Keep reading
All articlesThe unreasonable effectiveness of plain SQL
ORMs are fine. Until they aren't. After a decade of building data layers on every framework we could find, we keep coming back to plain SQL — and the patterns that make it pleasant.
Why we don't write microservices anymore
We split into microservices because it was 2019. Then we spent three years feeling the cost. Here's what we learned, and how we structure backends in 2025.
Why your first ML model should be embarrassingly simple
The first model in production teaches you more in a week than a perfect model in a notebook teaches you in a quarter. A practical case for shipping something terrible — on purpose — first.