There's a real temptation to say yes to an unreasonable deadline in the moment, especially early in a client relationship — it feels like the accommodating, can-do answer. The cost shows up later, usually as either rushed, lower-quality work or a burned-out week that quietly resents the client who "made" you do it, even though you're the one who agreed. There's also a more precise, research-backed reason to be skeptical of deadline estimates in general — including, uncomfortably, your own.
The research behind why deadlines go wrong in the first place
Daniel Kahneman and Amos Tversky identified what they called the planning fallacy: a well-documented, extensively replicated tendency for people to underestimate how long a task will take, even when they have direct past experience of similar tasks running long. It's not a failure of effort or honesty — it happens because people naturally estimate from an "inside view," focusing on the specific details of this particular task and how it's supposed to go, rather than an "outside view" that references how comparable tasks actually went in the past.
One of the clearest illustrations of this comes from a now-classic study: psychology students were asked to predict how long their senior thesis would take, including a worst-case estimate. The actual average completion time came out to 55.5 days. Only about 30% of students finished within the time they'd originally predicted. Even more strikingly, only 19% finished by the date they'd personally assigned a 75% chance of hitting — meaning the large majority missed a deadline they themselves had rated as fairly likely to make.
This cuts both ways, and it's worth being honest about that
It's tempting to read the planning fallacy purely as ammunition against an unreasonable client — proof that their proposed deadline is unrealistic. It's worth being honest that the same research applies with equal force to a freelancer's own gut-feel estimate of how long their work will take. If your instinctive sense of "this'll take about a week" isn't checked against anything, it's subject to exactly the same optimistic, inside-view bias the research describes — regardless of how experienced you are, since the original studies specifically found the bias persists even among people with considerable direct experience of past schedule failures.
This matters practically: the goal isn't to develop a reflexively skeptical posture toward every client deadline. It's to replace gut-feel estimation — on both sides — with something closer to what the research finds actually produces accurate predictions.
Two concrete techniques for a more realistic estimate
Take the outside view
Rather than imagining how this specific project will unfold, look at how your last several comparable projects actually went — not how you estimated they'd go, but the real elapsed time from start to finish. Research on the planning fallacy consistently finds that referencing actual past data produces more accurate predictions than reasoning through the specifics of the current task in isolation, precisely because the inside view tends to imagine a best-case path that rarely matches how projects actually unfold.
Use the segmentation effect
Breaking a project into its real sub-components and estimating each one individually, then summing them, tends to produce a longer — and more accurate — total than estimating the whole project as one block. It's easy to eyeball "a week" for a deliverable that, broken into research, drafting, internal review, and revision time, actually adds up closer to two.
Both techniques take a few extra minutes before quoting a timeline, and both directly counter the specific mechanism the planning fallacy research identifies as the cause of the bias in the first place — which makes them more useful than simply trying to "be more realistic" by force of will, since the original studies found that effort and good intentions alone don't reliably overcome the bias.
A worked example
A copywriter is asked to quote a timeline for a six-page website rewrite. Gut instinct says "two weeks, maybe a bit less if things go smoothly" — a number that feels reasonable without any particular data behind it, the classic inside-view estimate the planning fallacy research describes.
Applying the outside view first: checking the actual elapsed time on the last four similar website rewrites shows they took 18, 24, 16, and 29 days respectively — an average well beyond the gut-feel "two weeks," and notably, every one of those four projects had also been estimated at roughly two weeks going in. The pattern repeating across four separate instances is exactly the kind of outside-view evidence the research finds people tend to ignore in favor of an optimistic inside view each time.
Applying the segmentation effect on top of that: breaking the six-page rewrite into research and interviews (4 days), first drafts (5 days), internal revision before client review (2 days), and two rounds of client revision at a realistic pace (6 days) sums to 17 days — closer to the outside-view average than the original gut estimate, and arrived at through two independent methods rather than instinct alone.
The copywriter quotes 3.5 weeks instead of 2. The client, mildly surprised, asks why — and the honest answer ("my last four similar projects actually averaged closer to three weeks, even though I initially guessed two each time") lands as more credible than a round, instinctive number would have, precisely because it's visibly grounded in something other than a guess.
The framework
- State the real timeline, not just "that won't work." — "Realistically, quality work on this takes [X weeks] — I can hit [date] if we start immediately with no delays on feedback, or [earlier requested date] with a reduced scope. Which fits better?"
- Offer a genuine alternative, not just a refusal. A flat "I can't do that" without an alternative reads as unhelpful. Presenting options — reduced scope, a rush fee, a slightly later date — keeps you the person solving their problem, not the person blocking it.
- If a rush is genuinely possible, price it as one. "I can compress the timeline to hit [date], but it would require prioritizing this above other client work — a rush fee of [$X / X%] would apply." This makes the tradeoff explicit rather than absorbing the cost of a compressed schedule silently.
Scripts for common versions of this conversation
When the deadline is simply unrealistic for the scope:
"I want to make sure this gets the quality it deserves — realistically, [scope] takes about [X weeks], based on how similar projects have actually gone for me. I can hit [requested date] with a reduced version focused on [core elements], or do the full scope by [realistic date]. Happy to talk through which makes more sense."
When the client has a hard external deadline (an event, a launch) they can't move:
"Understood that [date] is fixed on your end. To make that work, I'd need [specific condition — e.g., all feedback within 48 hours, no more than 1 revision round]. If that's workable, let's proceed on that basis."
When you're already at capacity with other clients:
"I'd genuinely like to help, but I'm not able to prioritize this over existing client commitments without doing a disservice to one or the other. I could start by [later date], or refer you to someone who might have more immediate availability."
What this protects, beyond the current project
A pattern of accepting deadlines you know are unrealistic trains clients — and yourself — to treat your stated timelines as negotiable defaults rather than real estimates. Holding the line once, clearly and without drama, tends to make future timeline conversations easier, not harder.
And building the habit of checking your own estimate against actual past data, rather than gut feel, means the timeline you're defending is one you arrived at the same rigorous way you'd want a client's deadline to be set — which makes it a much easier position to hold with genuine confidence.
Timeline conversations start before the deadline does — the delivery dates and feedback windows you're defending are usually the ones set in a kickoff note:
Related guideThe Complete Freelance Project Kickoff Email
FAQ
What if the client says another freelancer already agreed to the timeline?
It's fine to hold your own estimate: "I can't speak to their process, but based on mine, here's what I can realistically commit to." Racing to match a competitor's possibly-unrealistic promise rarely ends well — and per the planning fallacy, that competitor's own estimate may itself be optimistically biased rather than genuinely achievable.
Is it ever worth just pushing through an unreasonable deadline once, as a favor?
Occasionally, for a high-value relationship or genuine emergency — but naming it explicitly as an exception ("doing this as a one-time accommodation, not the standard turnaround") prevents it from becoming the expected baseline.
How far in advance should timeline concerns be raised?
As early as possible — ideally during initial scoping, before a deadline is verbally agreed to, since pushing back after a date is already set is a harder conversation than negotiating it from the start.
Does pushing back on deadlines make me seem less capable?
Generally the opposite — a freelancer who gives a realistic, confident timeline reads as more competent than one who agrees to everything and occasionally delivers late.
How can I tell if my own deadline estimate is realistic, or if I'm falling into the same optimism bias I'd push back on in a client?
Check it against actual data from your past projects rather than trusting your gut feel for this one — research on the planning fallacy finds people consistently estimate more accurately when referencing how similar past tasks actually went (the "outside view") than when imagining how this specific task will unfold. If you've never tracked actual completion times against your estimates, that's worth starting, since the bias applies to freelancers' own timelines as much as to client-proposed ones.
A realistic timeline, checked against real data rather than gut feel, is a stronger position than instinct alone.