'Two Weeks, I Promise': The Lie We Tell Clients and Ourselves

Source: Dev.to

If you’re a developer, “estimation” is probably your least favorite word. It’s the moment you stop being an engineer and start being a psychic—usually a bad one.

In my role, I’m the one who provides the time estimate, and I’m also the one who has to do the work. You’d think that would make me the perfect estimator, right? Wrong. It just means I have nobody to blame but myself when I’m still debugging at 3 AM on a Saturday.

Here is the truth about why estimations are a nightmare and how we can stop the bleeding.

Part 1: The Problems (The “Expectation vs. Reality” Gap)

1. The “I’ll Know It When I See It” Client

Estimating for a client with no clear requirements is like trying to buy groceries for someone who “just wants something tasty.” You guess, you buy it, and then they tell you they’re allergic to everything you picked.

• The Reality: Without a spec, a “simple login page” quickly turns into “a login page with social auth, two‑factor authentication, a ‘forgot password’ flow that sends a carrier pigeon, and a dark mode.”

2. The “Ideal World” Fallacy

We estimate as if we are robots living in a vacuum. We assume:

• The API documentation is actually correct (it never is).
• The internet won’t go down.
• We won’t spend six hours on a missing semicolon.
• Our brains think we are the 10× developer from the movies, but our productivity is actually at the mercy of how many times the cat jumps on the keyboard.

3. The “Life Happens” Factor

You estimated 40 hours for a project. But you forgot about:

• The 10 hours spent in “quick” meetings for other projects.
• The “urgent” bug fix for a previous client that took a whole afternoon.
• The fact that you actually need to sleep, eat, and occasionally talk to your family so they remember what you look like.

Part 2: The Solutions (How to Survive)

1. The “Ambiguity Tax”

If a requirement is vague, the price goes up. Period.

• The Fix: If the client says “I want a search feature,” and gives no details, add 50 % to your estimate. That’s your “I have to figure out what you actually want” tax. If they want it cheaper, they have to be clearer.

2. The “Buffer” is Your Best Friend

I used to feel guilty about adding a buffer. I felt like I was “lying.” Now I realize that not adding a buffer is the lie.

• The Rule: The 1.5× multiplier. Take your most realistic, honest estimate and multiply it by 1.5. If you think it’ll take 10 days, tell them 15.
• The Pro Move:
  • Finish in 12 days → you’re a hero.
  • Finish in 14 days → you’re still early.
  • Finish in 10 days → you’re a god.

3. Use the “Pessimistic” Formula

Stop giving one number. Use the PERT (Program Evaluation and Review Technique) formula. It forces you to think about the “Pessimistic” scenario.

Where:

• O = Optimistic: The “everything works on the first try” miracle (10 %).
• M = Most Likely: The realistic middle ground (70 %).
• P = Pessimistic: The “everything broke and I have no internet” disaster (20 %).

When you actually write down how long it will take if everything goes wrong, that final number (E) becomes a lot more grounded in reality.

4. Manage “Clock Time” vs. “Deep Work”

Stop thinking in 8‑hour days. No one does 8 hours of coding.

• The Real Math: You probably have 4 hours of high‑quality “Deep Work” per day. The rest is eaten by emails, Slack pings, and personal life.
• The Fix: If a project is 40 hours of work, that’s a two‑week project, not a five‑day project.

The hardest part of estimation isn’t the math; it’s the courage to tell a client that their “simple” idea is actually a complex project. It’s better to have a hard conversation about the timeline before the project starts than a desperate conversation about why you’re late after the deadline has passed.

Next time you’re about to say “It’ll take a week,” take a breath, think about your cat, and say “Three weeks.” Your future self will thank you.