27. Do Not Lower Your Estimations Just To Please The Client

As a junior developer, I fell into this trap so many times. Going along with the pressure from the project manager and saying something could be done in less time, while I actually knew it couldn't.

And then exactly what you secretly already knew happens: it's not finished on time, the client is unhappy, the pressure goes up, and you end up working evenings or weekends "just to get it done" because somehow it really must be finished.

That lesson stayed with me for years: an unrealistic estimate is not a service, it's a time bomb.

Why we still lower our estimates

It is very tempting to say something is possible when it really isn't. Often, things like this are at play:

• You want to be helpful and "think along" with the client.
• The project manager is pushing: "Can't it be done a week earlier? It's really important."
• You don't want to come across as "slow" or "difficult".
• You think: "If I just put in a few evenings, it might work…"

But here is the problem: if you systematically sacrifice realism, you will eventually sacrifice quality, health, and trust.

What goes wrong when you lower your estimate

In the short term it feels nice: everyone is happy, the plan looks achievable, you appear "flexible". In the long term, you pay the price:

• Technical debt – You start taking shortcuts to hit the deadline. Tests get skipped, architecture becomes shaky, bugs pile up.
• Burn-out risk – Evenings and weekends become your "buffer". That is not professionalism, that is self-exploitation.
• Loss of trust – You deliver later than promised. Not once, but repeatedly. The client learns: "Their planning is never accurate anyway."
• Bad reputation for the whole team – One wrong promise feels to the client like: "This dev team never delivers on time."

A honest, firm estimate that turns out to be correct is far more valuable long term than a nice promise that keeps failing.

Being wrong is fine. Deliberately mis-estimating is not.

Of course you can be off sometimes. That's part of software development.

• You understood something differently than it turned out to be.
• You didn't have all the information when you made the estimate.
• Extra work was added later.
• There were technical issues, a sick colleague, or "unknown unknowns" nobody predicted.

That is normal. It happens all the time.

The difference is this:

An honest estimate can turn out to be wrong afterwards. A deliberately lowered estimate was already wrong at the moment you gave it. The first one is a learning opportunity. The second one is unprofessional.

As soon as you know it will slip: speak up

This is crucial: do not wait until it has already gone wrong.

The moment you can see that the original estimate is no longer realistic, raise your hand. The earlier you do that, the more options you still have:

• Adjust scope (define an MVP).
• Move the deadline.
• Bring in extra capacity.
• Reprioritise work.

Most clients would rather get a timely, honest update than a late surprise.

"It is not going to work as planned, here's why, and here are the options," is much stronger than: "Sorry, we didn't hit the deadline."

How to make stronger, more realistic estimates

A few practical tips:

• Think in ranges, not single dates. Instead of: "This will be done in 5 days." Say: "I expect 5 to 8 days, depending on X and Y."
• Break large features into smaller pieces. Big, vague features are impossible to estimate reliably. Split them into small, concrete chunks and estimate those individually.
• Write down your assumptions explicitly. For example: "This estimate assumes the design is final.", "We assume no major refactor in component X." If an assumption changes, it is logical that the estimate changes too.
• Include risk and uncertainty in your estimate. New system? New integration? New technology? Add explicit buffer and say there are risks.
• Say "I don't know yet" more often. You are allowed to ask for time to investigate. A day of discovery can save you weeks of stress later.

How to say "no" without being difficult

Here are a few phrases that can help you stay firm but constructive:

• "If we can't move the deadline, we'll need to reduce the scope. Let's look at what is really the minimum."
• "If I say it can be done in a week, I would basically be lying. Realistically we're talking about two weeks. I'd rather be honest now than fail later."
• "We can try to squeeze it into less time, but then I'll have to cut corners on quality and testing. I don't recommend that. Do you want to take that risk?"

You are not being difficult when you say this. You are behaving like a professional.

Remember: you're not a pleaser, you're a professional

A good developer is not the one who says "yes" the most. A good developer is the one whose "yes" people can rely on.

• Do not lower your estimates just to be liked.
• Do not lower your estimates just to "go along".
• Do not lower your estimates thinking "I'll just work extra hours to make it fit."

Be honest, be clear, and protect both your client and yourself.

Do Not Lower Your Estimations Just To Please The Client. Your future self – and your client – will thank you.