Guides
How to build an hours budget for a project
Estimate by task, add a contingency you can name, and review against reality every week. A method that works whether you sell fixed price or by the hour.
An hours budget is not a prediction. It is a tripwire: a number that tells you early enough that the project is drifting, while you still have room to react.
Building one takes half an hour and saves you the worst conversation with a client: the one where you explain why the work took twice the hours you had promised.
Estimate at task level, not at project level
“This project is about three weeks” is not an estimate, it is a wish. Split the work into tasks and give each one a number of hours, even if the number is rough.
Task-level estimates have three advantages: they are easy to correct one by one, they reveal which tasks are actually expensive, and they let you compare the estimate with the hours logged on that specific task instead of the whole project.
- Group small tasks: anything under two hours can live inside a larger item.
- Estimate the boring parts too — reviews, meetings, documentation and the back-and-forth with the client.
- Write the assumption next to the estimate when it matters (“assuming the API already exists”).
Add contingency you can name
A 100% estimate is a promise nobody can keep. Add a contingency to the total, and write down what it is for: unclear requirements, third-party dependencies, or the client's approval loop.
Nameable contingency can be defended. An invisible 30% “just in case” becomes a discount the day the client asks why the budget is higher than the sum of the tasks.
Review weekly and decide early
The budget is only useful if you compare it with reality while the project is running. Once a week, look at consumed hours against completed work and ask one question: at this pace, do we finish inside the budget?
If the answer is no, you have three options and all of them are cheaper now than in a month: reduce scope, move the deadline, or agree on more hours. Pick one and write it down.
Frequently asked questions
- How much contingency is reasonable?
- Between 10% and 20% for work you have done before with a known client. More when the requirements are still moving or when a third party has to deliver something first.
- What if the client adds work mid-project?
- Treat it as a new estimate with its own hours. Adding tasks to a project without touching the estimate is how a project that fitted becomes one that does not.
- Does estimating not slow the team down?
- The first time, yes: half an hour per project. After that you reuse the estimates of similar tasks, and the board starts telling you which kinds of work you systematically underestimate.