An estimate is a promise. Treat it like one.

The word “estimate” does a lot of heavy lifting. For some teams it means a gut-feel number in a proposal. For us it means a specific thing. A per-developer commitment, with hours or a fixed price, that someone has to approve before work starts.

Draft, submitted, approved

An estimate starts as a draft. The developer who will do the work fills in estimated hours and either an hourly rate or a fixed price, and the total computes itself. Start and end dates go on. Then it gets submitted.

From there it moves through a real workflow. Approved, rejected, or sent back for a re-edit. A rejection carries a reason. A re-edit carries a note. Nobody has to guess why a number came back, because the reason travels with the record.

This sounds like process for the sake of process until the first time a client disputes a bill and you can point to the exact estimate that was approved, by whom, and when.

Estimates know whether the work is done

An approved estimate is not the end of the story. It carries a work status of its own, from not started to in progress, work completed, and ready for payment. That last state is the hinge between the project side and the money side. When work is marked ready for payment, the payout that follows is tied to the estimate it came from, so the amount paid and the amount remaining are always current, per developer.

You approve an estimate in two clicks. You see the remaining balance without doing math. That is the bar we hold estimation to.

Fixed price or by the hour

Some work is billed hourly. Some is a flat number you agreed to and have to live with. Estimations handle both. Set an hourly rate and hours, or set a fixed price, and the payout tracking behaves the same either way. The pricing model is a property of the estimate, not a different tool.