How to respond when you are asked for an estimate

Answer with a range, the part nobody has measured yet, and the date you tighten the number. Why the deadline question fails and what to measure first.

No contractor prices a foundation before the soil test. In software, the drill is opening the piece nobody has looked at.

When someone asks you for an estimate, answer with three things in the same breath: a range, the part nobody has opened yet, and the date you will come back with a tighter number.

Out loud it sounds like this: "three to five weeks. Nobody here has looked inside the billing integration yet. Give me until Thursday, I'll measure that piece and come back with a narrower range." It is uglier than a single number and it holds up far better a month later. Because the person asking rarely wants a date. They want to know whether they can promise something to somebody else, and how long that promise will survive.

The question I used to ask, and the whiteboard that never helped

A range doesn't come from a guess. It comes from half an hour inside the module nobody has touched since 2021.

My first company rented construction equipment. I hired developers without being able to judge a word they said. My ritual never changed: I asked how long it would take, the dev said a number, I wrote it on the whiteboard and went out selling that date to customers and to my co-founder. The sprint ended without the feature. Every single time.

It took me the better part of a year to accept that the dev was not the problem. He answered precisely what I asked. I wanted a number, he gave me a number. What I actually needed was the part he could not know yet, and the way I framed the question, saying "I don't know yet" sounded like incompetence. So nobody said it.

This is not a rare setup. The question "how to respond when you are asked for an estimate" sits on Software Engineering Stack Exchange with a score of 717, 17 answers and over 251,000 views. Nobody piles up that much reading on a solved problem.

No contractor prices a foundation before the soil test

Before I traded steel beams for slow queries, I signed off technically on industrial steel assembly. Construction has a ritual that software treats as a luxury: before any foundation quote, somebody drills the ground in a few spots. It costs a rounding error against the project and it rearranges everything. Loose sand down to eight meters and the footing becomes a pile, which moves the price into another bracket.

No client on a building site finds that offensive. Nobody calls the engineer demanding a foundation price before the drilling. In software the same request lands in your inbox daily, usually dressed up as "just a ballpark, I won't hold you to it." They will hold you to it. A number said on a Wednesday call becomes a line in a launch plan the following week.

Our version of the soil test is just as cheap. Half an hour inside the module nobody has touched since 2021. An afternoon booting the environment from scratch on a clean machine to count the missing steps in the README. A look at last month's error log. That is measurement, not estimation. And measurement is what shrinks the range.

Three risk questions instead of one deadline question

The date that survives is the one with a revision already on the calendar from day one.

When someone on the team hands me a date, I hand back three questions. They move the outcome more than any pointing ceremony ever did:

• What has nobody opened yet? Every scope has a piece the team described from memory and never looked inside. That is where most of the overrun comes from.
• What depends on people who don't sit with us? Third-party approval, a vendor credential, a client staging environment. Deadlines don't only die from code, they die from waiting.
• What has to be measured before I tighten this range? If the answer is "nothing," either the team already measured, or someone is guessing in a confident voice.

None of them asks how long it takes. All three hunt for variance, which is the part that hurts. A wrong average you fix next week. A three-week spread kills a launch.

"But I need a date for the board"

That is the honest objection, and it is right. You are not walking into a board meeting saying "it depends." But a range with a revision date gives you something the single number never did: a second checkpoint everyone agreed to in advance.

"Three to five weeks, and next Thursday I'll tell you whether it's three or five" is a sentence executives accept. What nobody accepts, fairly, is the surprise the night before. Anyone who has bought engineering knows the difference between a project that slips and a project that slips quietly. It is the same trap I wrote about in the estimate that wins the deal: the sharpest number in the bid is usually the one that moves the most.

If your procurement demands a fixed bid before anyone looks at the system, split the measurement from the build. One or two paid weeks of discovery with a written deliverable, full proposal after. Set that against a blended rate and a lost quarter, and discovery is the cheap line on the invoice. Rate context is here if you need it: software developer rates in Brazil.

AI multiplied the output and never touched the queue

Here is the new part, and it caught a lot of teams off guard this year. You rolled out coding assistants, pull request volume went up, the feeling of speed went up with it, and the date the customer is holding you to sits exactly where it was.

I ran a script over the pull requests in one repository so I could stop arguing from vibes. Median wait for a human to look at a PR came out at 19.4 hours. That is not writing time. That is finished code parked, waiting for someone with enough context to review it. Writing was never the bottleneck, and speeding up the only fast stretch just makes the queue behind it longer.

The side effect on estimates is sneaky. With an assistant, a dev drafts the feature in two hours and feels the card is done, so the range they quote gets shorter. What did not get shorter: review, tests that actually assert something, integration, and the ten-year-old part of the system the model has never seen. The bill gets more expensive because the promise got shorter while delivery stayed the same.

One short detour. I watched an assistant generate 14 tests for a module I already knew was broken, all green. The metric existed, the guarantee did not. An estimate built on a green dashboard is a guess with a report attached.

The villain is in the contract

The contracting model that demands a fixed date before any measurement is what keeps this loop alive. It forces the vendor to guess, rewards whoever guesses lowest, and then bills the client for the difference in cut scope, tests that don't test and a health endpoint returning 200 while monitoring nothing.

The same person always pays. A shop that agrees to beat the price did not discover a cheaper way to build. It removed something from the delivery, and it removed exactly what the buyer cannot evaluate. That is why our teams measure before promising: a range that survives month three is worth more to everyone than a pretty number in the proposal. And it is fair to say this discipline does not stop you from being wrong, it only shortens the error. I also don't know that it holds for a three-person team on an internal product, where the deadline is your own and the cost of a miss lands in your own lap.

Take the last project that slipped at your company and look for one specific date: the day someone first opened the ugliest piece of the scope. If that day came well after kickoff, the delay was already in the contract before the first line of code. What would it have cost to measure that piece before you signed the date?