I have lost money on projects that I priced myself. Not because the client was difficult or the team was slow, but because I built the estimate on assumptions I never wrote down. The budget looked healthy in the proposal and bled out in month two.
After enough of those, you stop treating estimation as a maths problem and start treating it as a risk problem. Here are the mistakes I keep seeing — most of which I made first.
1. Estimating the happy path and calling it the budget
Ask a developer how long a payment integration takes and you will hear “three days.” That three days is the happy path: credentials work, the sandbox behaves, the docs are accurate, nobody changes the requirement halfway.
The real timeline includes the gateway account that takes a week to approve, the webhook that fires twice in production, and the client who decides they also want partial refunds. None of that is scope creep. It is the same feature, honestly costed.
A fix that works: estimate every task three times — best case, likely case, worst case — and use the weighted formula (best + 4 × likely + worst) / 6. On a 3 / 5 / 12 day task that gives you about 5.8 days, not 3. Do this across twenty tasks and your budget stops being a wish.
2. Forgetting that developers do not code eight hours a day
This one quietly destroys more budgets than anything else. You estimate 200 hours of work, divide by an 8-hour day, and promise 25 days. Then you wonder why it took 40.
Nobody delivers 8 productive hours. Between standups, code review, client calls, Slack, context switching between two projects, and the half hour after lunch where nothing happens, a realistic figure is 5 to 6 billable hours per developer per day. On a team that also handles support tickets, it is closer to 4.
So 200 hours of work is 33–40 working days, not 25. If you have been consistently 30–40% over on delivery dates, this is probably the whole explanation. Track actual logged hours against calendar days for one month on your own team and use your real number instead of mine.
3. Pricing only the code
Development is often 50–60% of what a project actually costs you. The rest is invisible in the estimate but very visible in the invoice you cannot send.
- Requirement gathering and clarification calls — easily 10–20 hours on a mid-sized project
- QA and bug-fix cycles — budget 20–25% of dev hours, not “we will test as we go”
- Deployment, server setup, DNS, SSL, staging environment
- Client review rounds — two rounds of feedback per module is normal, and each round has a cost
- Project management time — 10–15% of total effort, and yes, it is billable work
- Third-party costs — licences, plugins, APIs, SMS credits, paid themes
- Post-launch stabilisation — the two weeks after go-live where things break
Add these up on your last project and compare against what you charged. The gap is usually uncomfortable.
4. Treating the contingency buffer as optional
Two things happen to the buffer. Either it never gets added because the number “looks too high,” or it gets added and then quietly spent in week one to cover a bad estimate.
Both are failures. A buffer is not padding you feel guilty about — it is the price of uncertainty, and uncertainty is real. My rough scale:
- 10–15% — work you have done many times, clear requirements, known stack
- 20–25% — new client, new integration, or requirements that are still fuzzy
- 30%+ — legacy code you have not seen, an undocumented API, or a client who says “we will figure out the details later”
And treat the buffer as a controlled resource. It gets released against a named risk that actually materialised, not sprinkled over every task that runs long.
5. Giving a firm number before you understand the problem
The most expensive sentence in this business is a price given in the first meeting because the client asked for a “ballpark.” That ballpark gets screenshotted, forwarded, and becomes the number you are negotiated back down to three weeks later when the scope has tripled.
Two things that work better than refusing to answer:
- Give a range with a stated confidence level. “Based on what I know right now, this looks like 8 to 14 lakh. To narrow that, I need to see your current database and the reporting requirements.” You have answered honestly and set the expectation that the range will move.
- Sell a paid discovery phase. A short, fixed-fee engagement that produces a proper scope document and a real estimate. Clients who refuse to pay for two weeks of discovery are usually the same ones who will refuse to pay for change requests later. That is useful information.
6. Never comparing the estimate to what actually happened
Most teams estimate, deliver, and move on. Nobody goes back to ask how wrong the estimate was, so the same errors repeat for years.
Keep a simple sheet: task, estimated hours, actual hours, variance. After five or six projects, patterns show up that no amount of intuition will give you. You will find that your team is 15% fast on frontend and 60% slow on anything touching a third-party API, or that every project involving data migration doubles. Then you stop guessing and start applying multipliers based on your own history.
This one habit improved my estimates more than any tool or template.
The takeaway
A budget is a forecast, not a promise, and it should be built like one — with ranges, explicit assumptions, and a buffer sized to the actual risk. Write down what your estimate assumes and attach it to the proposal. When something breaks that assumption, you have a conversation about a change request instead of an argument about who is at fault.
Start with two changes on your next quote: use a realistic productive-hours number, and log actual versus estimated hours. Those two alone will move you closer to profitable than any spreadsheet template.
