Software Project Estimation: Price by Risk, Not Hours

When a client asks "how much will this cost?", the instinct is to estimate hours. Multiply by rate. Add a 20% buffer. Send the number.

I did that for three years. Then I added up how many of those "buffer hours" actually went to genuinely unforeseeable problems — and realized my estimates were systematically wrong. Not because I'm bad at math. Because I was answering the wrong question.

Why estimating in hours gets it backwards

Hofstadter's Law: everything takes longer than you expect, even when you account for Hofstadter's Law. It's not about procrastination. It's about the fact that uncertainty in projects can't be resolved by adding padding.

Hours represent the cost *if everything goes to plan*. Legacy projects don't go to plan — not because developers are slow, but because a chunk of the work isn't visible until you start digging.

On one Bitrix project, we estimated an integration with an external 1C system at 40 hours. It took 130. Not because the developer didn't know what he was doing. Because the 1C API turned out to be documented the way was convenient for them, not the way it was described. That risk wasn't visible at presales.

Hours answer "how long?" Risk answers "what could go wrong?" Those are different questions — and the second one matters more on software project estimation.

Three risk categories no one asks about during presales

I break project risk into three blocks before touching a calculator.

First: technical risk. How well do I understand the codebase? Is there documentation? How predictable are the external APIs I need to integrate with?

Second: organizational risk. Who makes decisions on the client's side? One person or a committee? Have I been in situations where a client goes quiet for two weeks mid-project?

Third: scope risk. Do we both understand what's included? Does the client have a real requirements list, or just a concept?

My checklist: nine questions before writing a number

Before any proposal involving non-trivial project risk estimation, I work through these — either silently or out loud with the client:

Do I have access to the code before the estimate, or am I pricing from a description?
Has anyone touched this codebase in the last 6 months, or has it been sitting?
Are there external integrations with closed or poorly documented APIs?
Who makes the final call on requirements, on the client's side?
Is there a hard deadline, or "as soon as possible"?
Is this greenfield or refactoring an existing system?
Has the client worked with developers on this project before? What happened?
Are there tests, or am I the first person thinking about that?
What happens to their business if we miss the deadline by three weeks?

None of these answer "how many hours" — they answer "how likely am I to be wrong about the hours."

What happens when you skip the checklist

About two years ago I got a request: add a customer order history section to a Bitrix site. Seemed clear. I gave an estimate on the spot, no questions.

Day two: I discovered the client had three different types of "orders" across three different tables, joined via a manual SQL view written by a contractor who'd since quit. No docs. No tests.

The project took 2.8× my estimate. The client was happy with the result, annoyed about the timeline. I was annoyed with myself — the risk was visible if I'd looked.

If I'd asked question 2, I'd have known the code had been sitting since last quarter. The estimate would've been different.

Red, yellow, green

After the checklist, I assign the project a color.

Green — I understand what needs doing, technical risk is low, the client has a clear scope. I estimate in hours with a small buffer.

Yellow — there are 1–2 unknowns. I quote a range (min/max) and name exactly what's unclear and when I expect to resolve it.

Red — too much that's unpredictable. I propose a paid discovery phase instead of a full estimate. Or I pass.

This sounds obvious. The gap between a "green" I'm pretending to see and a real green is the gap between a calm project and a painful one.

I turned down a $40K contract because the project was red: a proposal to rewrite a Bitrix monolith without understanding what was actually causing performance problems. That story is here.

How AI tools changed my estimation formula

In 2023, AI assistants started actually changing how fast some tasks get done. A task that once cost 20 hours of routine code might now cost 6. But the project doesn't become 3× cheaper.

The pattern I've seen: where AI speeds up code writing, the QA tail stays the same or gets longer. Because AI writes confidently without always being right. I've watched a task — "write this API integration" — go from 15 estimated hours to 5 hours of code and 10 hours of checking.

AI shifts the distribution of work. It doesn't remove risk. The checklist matters more now, not less.

When I decline during scoping

Red flags that make me stop and propose discovery instead of an estimate:

The client can't answer "who makes the final call on requirements"
"We have a spec" — but it's a wishlist with no priorities
The previous developer "disappeared," and the client isn't sure why
The project was started once, stopped, and the reason isn't clear

This isn't refusing the work. It's switching the format: discovery costs X, and after that I can give a real estimate. Clients who accept that are usually worth working with.

Estimating in hours isn't wrong. It's just the last step, not the first.

Risk first. Color second. Hours third.

If someone on your project is right now estimating hours without asking any of those nine questions, that's worth a conversation. Better to slow down at presales than to explain a slipped deadline to someone who trusted your number.