A technical estimate is a claim about the future, and the future does not cooperate. So the worst thing an estimate can do is pretend otherwise. "This feature is 47 hours" reads as confident, but the confidence is fake — nobody knows it is 47 rather than 35 or 70, and pretending you do just means you will be wrong with a straight face. The estimates I trust, and the ones I write, do the opposite. They show their work. They say what they assumed, what would push the number around, and what could go wrong, so the reader can judge the estimate instead of just swallowing it.

The format I keep coming back to is small on purpose: one feature, one page, and four sections — an estimate, the assumptions under it, the drivers that move it, and the risks. Everything else is noise.

State your assumptions, in writing#

Every estimate sits on a pile of assumptions. The only question is whether they are written down. Write them down. An assumption block does two jobs: it makes the number defensible ("this holds if these things are true"), and it converts surprises into change orders instead of arguments. When something on the list turns out false, you have a shared document showing the estimate never covered it.

Be concrete about scope on both ends. Say what is included — the specific endpoints, environments, integrations, surfaces the number covers. Then say what is explicitly excluded, because exclusions are where estimates die. "Authentication" quietly means signup, login, refresh, reset, and admin management; whether it also means single sign-on, social login, or biometrics is exactly the kind of thing that should be stated, not assumed. If a component scales by some count — environments, client surfaces, templates, integrations — name the multiplier so nobody mistakes the base case for the whole thing.

Name the drivers that move the number#

A single number hides the fact that the estimate is really a function of a few variables. Make those visible. List what pushes the estimate up and what pulls it down, in plain terms a non-engineer can follow.

Drivers up are usually added surfaces, compliance requirements baked in early, extra integrations, richer permission models, or anything that multiplies. Drivers down are fewer environments, narrower scope, dropping the optional pieces. This section is doing two things at once: it gives a reader the levers to adjust the estimate for their situation, and it pre-negotiates the change orders. When the client later asks for the second platform or the SSO option, the estimate already said that costs more, and by roughly how much.

Surface risks with mitigations attached#

Risks are not a disclaimer you bolt on to cover yourself. They are the part of the estimate where you demonstrate you have actually built the thing before. For each one, name the risk, say what it would cost you if it landed, and state how you would head it off.

The pattern that earns trust is risk plus mitigation, never risk alone. "Large file uploads can fail on weak connections" is a worry. "Large uploads can fail on weak connections, so we compress client-side, chunk big files, and retry with backoff" is a plan. The first makes you sound nervous; the second makes you sound like someone who has shipped this. Good risks tend to cluster in predictable places: third-party provisioning that takes longer than anyone expects, compliance requirements that surface late and force rework, anything best-effort being treated as guaranteed, costs that run several times your estimate at production scale, and integrations whose quirks you will not discover until you are inside them.

Give a range, and a confidence#

When the estimate itself is genuinely uncertain, say so with a range rather than a point. A range is not hedging — it is more information, because it tells the reader how wide the cone of uncertainty actually is. "12 to 16 hours" communicates something a flat "14" cannot: that you know where the slop is. Pairing the number with an explicit confidence level does the same job. A low-confidence estimate is a signal to go reduce the uncertainty — with a spike, a prototype, a conversation — before anyone commits to the figure.

A few habits that keep estimates honest#

• Keep each estimate to one feature. Bundling features into a single number hides where the cost and the risk actually live. Estimate the pieces, then sum.
• Reuse a stable assumption block. If you estimate the same kinds of components repeatedly, write the assumptions once and reuse them verbatim. Consistency makes drift obvious and saves you from re-litigating the same scope every time.
• Estimate the work, not the worker. Be explicit about the basis — one person, with whatever tooling and assistance you are counting on. Change the basis and the number changes, so state it.
• Recommend the pre-work. The cheapest risk mitigation is something done before development starts: confirming account access, checking the compliance posture, verifying a third-party credential exists. Call those out as pre-development actions so they are not discovered on day one.
• Let an estimate kill a feature. Sometimes the honest number reveals that a requested feature costs far more than it is worth. Surfacing that early is the estimate doing its most valuable job.

The throughline is simple: an estimate's job is not to be exactly right, which is impossible, but to be honestly wrong in a way the reader can see coming. State what you assumed, name what moves it, show what could break, and give a range when you are not sure. Do that and people stop treating your numbers as promises to be broken and start treating them as the considered judgments they are.