Three weeks. That's what most developers say when a client asks how long a "simple" integration will take. It's also, almost never, what actually happens.

Not because the developer is bad at their job. Because the estimate was never really about the work. It was about the version of the work everyone hoped for — no undocumented legacy system, no client who "just needs one small change" in week two, no third-party API that returns 200 OK on requests that quietly failed. That version doesn't exist. So the estimate was fiction from the moment it left someone's mouth.

Where the number actually comes from

Ask a developer for an estimate and watch what happens in their head. They picture the happy path: clean requirements, a stable API, a client who responds to Slack messages within the hour. Then they add a buffer, because they know better. Then the client pushes back on the buffer, because it looks padded. What ships is a number that satisfies nobody and predicts nothing.

The estimate isn't wrong because of bad math. There was no math. It was a guess, formatted to look like one.

The part nobody tracks

Here's the thing almost no one does: go back and check. Pull up the last ten projects. Line up what you quoted against what you actually delivered. Most people who do this for the first time are shocked — not that they were off, but by how consistently off, and in the same direction, every time.

That pattern is the most useful data you have, and almost nobody uses it. If your integrations run 40% over on average, that's not a discipline problem. That's a multiplier. Apply it.

What actually moves the number

Fix the estimate by fixing what feeds it, not by trying harder to guess correctly.

Break the work down until each piece is small enough that you'd stake your reputation on it. "Build the checkout flow" is a guess. "Wire the existing cart to Stripe's payment intents API, assuming the current cart schema" is closer to a fact — because you can check whether that assumption holds before you commit to a number.

Say "I don't know yet" out loud when you don't. A client hears this far better than a wrong number delivered with false confidence, and it buys you the day or two you need to actually look at the system before quoting it.

Track the gap every time, not just when a project blows up. One data point tells you nothing. Twenty tell you exactly how much to pad, and for which kind of work.

Separate "time to build" from "time to figure out what to build." Most estimate failures live in the second bucket — the unknown unknowns, the API that lies about its own documentation, the client who didn't mention the other three systems this needs to talk to. Quote them as different lines. Let the client see where the risk actually sits.

The estimate that's worth something

A good estimate isn't the number you're most comfortable saying out loud. It's the number you'd bet your own money on, because you checked instead of guessed. That takes ten more minutes upfront and saves the awkward call in week five where you explain why "three weeks" became two months.

Most estimates aren't wrong because the work is unpredictable. They're wrong because nobody bothered to make them true before writing them down.