How much buffer a freelancer needs in estimates and calendar

The Wednesday a contact form broke

It was a good week on paper. Every billable hour was booked: app work in the mornings, a site build in the afternoons, and one maintenance retainer that usually needs about an hour a week. I had even put the school run and a delivery window into the calendar so nothing would surprise me.

On Wednesday at half nine, the maintenance client emailed. A plugin update overnight had broken the contact form on their site, and enquiries were bouncing. That is a genuine emergency for a small business, so I dropped everything. The fix took three hours, mostly because the error only appeared on one mail provider.

Those three hours had to come from somewhere, and there was nowhere for them to come from. The app work slid to the afternoon, the site build slid into the evening, and by Friday I had apologised to two clients for things that had nothing to do with them. One small, ordinary problem had knocked over the whole week because I had planned it with zero slack.

That is what buffer is for. It is not padding to cover for laziness. It is the space that lets one bad hour stay one bad hour.

Three buffers that do different jobs

I think about buffer in three separate places, because mixing them up is how people end up with none.

Estimate buffer lives inside the quote: extra hours for the unknowns in the work itself.

Calendar buffer lives in the week: unbooked time so that a slip, or a broken contact form, does not cascade.

Cash buffer lives in the bank: enough runway that one late invoice does not push you into a bad decision. That one belongs in your rate and savings plan, and calculate a freelance hourly rate covers it better than I can here. A quick sense check: if a client pays 45 days after invoice, you need six to seven weeks of expenses covered just to wait for one payment.

The rest of this is about the first two, because those are the ones freelancers skip while telling themselves they are being efficient.

How much estimate buffer, by how well I know the work

These are my own planning defaults, built from my timesheets. They are not industry statistics, and yours should come from your own history once you have some.

That last row came from a site migration. The work itself was about three days, and I knew it well. What I did not know was that the client's hosting account was registered to someone who had left their business two years earlier. Getting access took four business days of support tickets and identity checks. A percentage buffer on three days of build would have added maybe a day. The real delay had nothing to do with how hard the work was, so scaling it from the build time made no sense.

Now, anything that depends on someone else's system or someone else's permission gets fixed days in the plan, and the estimate says plainly that the date starts once access works. When scope is fuzzy, I give a range rather than a single number: "five to seven working days after the copy is final" is more honest than "five days" when the copy is still moving.

Feedback is a line in the plan, not a gap in it

Every review round takes calendar time, even if it takes almost none of your hours. You cannot build the next thing properly while waiting to hear whether the last thing was right.

So I write the waiting into the estimate: "includes two rounds of feedback, each returned within three business days." If a round takes a week, the date moves, and the estimate already said it would. Without that line, you absorb the delay quietly and the client learns that slow replies cost nothing. Client feedback delays and pricing goes into the wording and the cost of a long silence in more detail.

Photograph

Calendar buffer: the half-day I no longer sell

After that Wednesday, I changed how I fill a week. Out of roughly forty working hours, about twelve go to things nobody pays for directly: email, invoices, quotes, a bit of learning. That leaves about twenty-eight hours I could bill. I book twenty-four and keep four empty, usually as a Friday afternoon.

Most weeks that half-day gets used for overflow: a review that ran long, a bug, a client call that moved. When nothing goes wrong, I use it for my own projects or finish early. Either way, an emergency now eats the Friday rather than everyone else's Wednesday.

The rule I keep is that slack is protected the same way deep work is. If a client wants that Friday afternoon, they get it only for something urgent, not because it looks free. And if the slack disappears three weeks running, the problem is not the buffer. Either I am taking on too much, or my estimates are too short, and billable hours being lower than working hours is usually part of why.

Fixed price needs the buffer in the number

On hourly work, buffer spreads itself across invoices. If something takes longer, it is billed. On fixed price, all the risk sits in one number, so the buffer has to be in the money, not in hope.

A recent example: my build estimate for a new client's site was thirty hours, which at €70 an hour is €2,100. New client, new hosting setup, scope that still had a couple of open questions, so I added thirty percent: thirty-nine hours, quoted at €2,730. If that felt too high for the client, the honest move was to cut scope until the risk fit, not to drop the buffer and keep the scope.

When the uncertainty is bigger than any sensible buffer, fixed price is probably the wrong model for that part of the job. Fixed price versus hourly goes into when each one carries risk better.

Counting focus blocks shows the optimism

One trick that keeps my estimates honest is breaking the work into focus blocks before I quote, the way I would actually plan the days (Pomodoro for client work describes how I use them). If a feature comes to eighteen blocks, and a real block for me is about thirty minutes once you include the break and getting back in, that is nine hours before any buffer.

The useful part is the gut reaction. If the block count scares me, the quote should too, and I shrink the scope until the count fits the calendar I actually have.

Which buffer to look at first when a project slips

When something slips, the instinct is to work late. I try to go through this order first:

1. Inputs. Did the client miss a date for copy, access or feedback? Move the milestone in writing before touching your evenings.
2. Estimate. Did unknowns win despite reasonable diligence? Say so early and suggest a second phase rather than silent heroics.
3. Calendar. Did another client's emergency eat the slack? That is a sign about capacity, not a one-off.
4. Cash. Are you working nights because a bill is due, not because the work needs it? That is a pricing or pipeline problem.

Jumping straight to the fourth while pretending the first did not happen is how a fixed-price project turns into resentment.

Buffer should shrink as you learn

Buffer is a forecast, so it should get better. After each project, I compare what I estimated (with buffer) against what it took, and adjust the table for next time. When a miss is mine and keeps repeating, I run a short estimate postmortem before the next quote.

Repeat clients on a stable stack earn smaller buffers. A client who always returns feedback in two days gets a tighter quote than one who moves the goalposts. The first project in a new framework carries a learning slice that the fifth project does not, and I write it into my private estimate even when the client only sees a date.

Patterns are the real prize. "Always needs an extra day for testing on this client" means the buffer for that client was too small every time, and now I know by how much.

When the buffered estimate does not fit their date

Sometimes the honest estimate, buffer included, lands after the client's launch date. Hiding the buffer to make the date fit helps nobody, because the work will still take the time it takes. What I offer instead is what fits: "We can ship the booking page and the menu by your date. The gallery moves to a second phase."

Buffer is how I tell the truth about uncertainty, in the quote, on the calendar, and to myself about what a week can hold. That Wednesday did not go wrong because a plugin broke. Plugins break. It went wrong because I had promised every hour of the week to someone, and left nothing for the one thing I could have been sure would happen: something unexpected.