Why Claude Code Project Timelines Get Estimated Wrong
Estimates go wrong because the thing that got dramatically faster is not the thing that consumed the calendar. AI compressed the writing of code. It did not compress waiting for the client to send their brand assets, or the two days of review after the first demo, or the afternoon lost to a domain registered to somebody who left the company three years ago.
So the builder does the honest thing and estimates from experience: this used to be four weeks of code, the agent makes me several times faster, call it one week. Then the project takes five, and the extra four weeks contained almost no code at all. Nothing about the reasoning was lazy. It measured the wrong quantity.
Split the Project Into Four Phases and Estimate Each Separately
Estimate four phases on their own, because they scale completely differently and only one of them is affected by how fast your agent is.
The four phases and what actually drives each one
| Phase | What it covers | Does the agent speed it up? |
|---|---|---|
| Discovery | Getting clear on what is being built, seeing their systems, agreeing scope | Barely. It moves at the speed of their availability |
| Build | Writing the thing | Enormously. This is the phase everyone quotes |
| Review | Your own verification, then their rounds of feedback | No. Review is judgement, and it is a human bottleneck |
| Deploy and handover | Domains, accounts, access, training, documentation | No. It is mostly credentials and permissions belonging to other people |
Write a number against each phase in your notes before you write a number in the email. The first time you do this the split is usually a shock. On small client builds it is common for the build phase to be a minority of total elapsed time, which means quoting the build and adding a bit for safety is structurally guaranteed to underquote.
Discovery is the phase most builders leave out of an estimate entirely, and it is the one that most reliably decides whether everything after it goes smoothly. If you are not running one properly, fix that before you fix your estimating - we covered it in [the discovery call for AI projects](/blog/discovery-call-for-ai-projects).
Estimate in Sessions, Then Convert to Calendar Time
Estimate the build in working sessions, meaning uninterrupted blocks where you and the agent are genuinely on the problem. Sessions are a unit you can judge from experience. Calendar days are not, because they also contain other clients, weekends, and everybody else's response times.
- Break the build into features you can name in one sentence each. Anything you cannot name in one sentence is two features hiding.
- Put a session count against each one. Most well-scoped features on a Claude Code build land at one to three. If something reads as more than five, it is not a feature and you have not finished scoping it.
- Add the phases around it: discovery sessions, your own review passes, deployment and handover. These are real work and they belong in the total.
- Convert to calendar time using how many of these sessions you honestly get in a week on this project, not how many exist in theory. For most people carrying more than one client that number is three or four, not ten.
- Add the client's response latency. If they take two days to answer and the build needs three decisions from them, that is six days of calendar no amount of speed removes.
The conversion step is where the honesty lives. Four sessions of work is not four days. It is four sessions plus the gaps, and the gaps belong to the client's calendar as much as yours. Skipping the conversion is how a genuinely accurate build estimate becomes a missed deadline.
The Unknowns That Actually Blow Up Timelines
Some categories of work carry far more variance than their size suggests. Price the variance instead of pretending it is not there, and name it on the call so the client hears it from you before it happens rather than after.
- Anything that integrates with a system you have not seen. An API you have not read is not an estimate, it is a guess. Ask for access during discovery and look at it before you quote.
- Anything that depends on the client's existing accounts. Payment processors, domain registrars, analytics, email providers - the work is minutes and the access is sometimes weeks.
- Anything involving their real data. Real data is always messier than the sample, and the cleanup is invisible until you have it in front of you.
- Anything with a compliance, legal or brand approval step. That is not your timeline. Ask who signs off and how long they usually take.
- Anything described as simple by somebody who is not building it. That word rarely survives contact with the actual requirement.
The move that removes most of this risk is charging for a short paid discovery before you quote the build. You look at the systems, read the API, see the data, and then give a number you can defend. Clients who will not pay for a couple of hours of scoping are usually the same clients who will not pay for the overrun either.
How to Present the Estimate So It Holds
Quote a range, tie the start to a named dependency, and list what you need from them in the same message. A range with conditions is a professional estimate. A single confident date with no conditions is a hostage you handed over for free.
- Give a range, not a point. Two to three weeks, not seventeen days. False precision buys you nothing and costs you the margin the moment it slips.
- Start the clock on their action. Two to three weeks from the day I have access to your site and the product copy. Now the date moves when they move, which is both fair and true.
- List the dependencies explicitly. Three or four bullets naming exactly what you need and when. This is the highest-value paragraph in the whole document.
- Name the review rounds. Two rounds of feedback included, each returned within three working days. Unbounded feedback is an unbounded timeline, and one line prevents it.
- Say what happens when scope changes. Not as a threat, just a mechanism: new requests get quoted as an addition rather than absorbed. The related trap is covered in [how to handle scope creep on client projects](/blog/how-to-handle-scope-creep-on-client-projects).
What to Do When You Are Going to Miss It
Tell them early, say specifically what changed, and give a new date with the same conditions attached. The damage from a slipped deadline is almost entirely about when they found out, not how late it was.
A client told in week one that the integration is worse than it looked and delivery moves by five days will usually say fine. The same client told on the delivery date will not, because they have already told somebody else, and you have made them look bad rather than merely late. Silence is the expensive part, not the delay.
Then write the real number in your notes next to the estimate. An overrun is only wasted if it does not calibrate the next quote. Two or three of those and your estimates stop being optimistic, which is worth more to your margin than any further speed improvement in the build itself.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How long does a typical Claude Code client project take?
It depends far more on the client than on the build, which is why a single number is not useful. The honest framing is that the coding phase is often a minority of elapsed time, and discovery, review rounds and access to the client's existing accounts consume the rest. Estimate the four phases separately and you will land closer than any rule of thumb.
Should I quote a fixed deadline or a range?
A range, tied to a named dependency such as the day you receive access and content. A single date implies a precision the work does not have and hands the client a stick if anything moves by a day. A range with conditions reads as more professional, not less, because it shows you have thought about what could change.
How do I stop client feedback from wrecking the timeline?
Put a number on it in the estimate: how many rounds of feedback are included and how many working days each one has. Unbounded review is the most common source of overrun on small builds precisely because nobody ever agreed it was bounded. One line fixes it, and clients rarely object because it also tells them when to expect the finished thing.
Does using Claude Code let me quote shorter timelines than other builders?
On the build phase, genuinely yes. On the total, much less than you would expect, because discovery, review, approvals and access are unaffected. Quoting the compressed build as though it were the whole project is the specific mistake that makes fast builders look unreliable, and it is entirely avoidable.
What should I do if the project is going to run over?
Tell the client as soon as you know, say specifically what changed, and give a revised date with the same conditions attached. Clients forgive delays they hear about early far more readily than delays they discover on the due date, because the early version lets them adjust their own commitments instead of being caught out by yours.
Last reviewed by Duncan Rogoff on August 19, 2026
