How to Tell a Client You Will Miss a Deadline on a Claude Code Build (Before They Find Out)

The Short Answer

Tell the client the moment you know the deadline is at risk, in writing, in a short message that answers four questions: what is late, why in one sentence, the new date you will actually hit, and what they can have on the original date. Then give them a choice wherever you can, so the slip becomes a decision they make with you instead of news they receive from you. That is the whole skill. Everything below is how to do it well.

That is the Early-Flag Rule: the earlier the warning, the smaller the problem. A client can rearrange a launch, a meeting, or a team's week if they hear a week early. They cannot do anything with news that arrives on the day. Most clients have worked with someone who went quiet and then missed a date, and the fastest way to stand out from that is to be the builder who flags early and then hits the new date.

Spot the Slip Before It Becomes a Miss

Builds rarely go late all at once. They go late a day at a time, and the signs are visible well before the due date if you look for them. Check your build against these every time you sit down to work on it.

• A piece you estimated as small has taken twice as long and is still not done.
• You are waiting on the client for access, content, or a decision, and the wait is eating the days you planned to build in.
• The scope has grown in small 'quick' requests that nobody priced or dated. [Stopping scope creep](/blog/stop-scope-creep-on-a-claude-code-project) covers how to catch these.
• Claude Code keeps producing code that looks right but fails when you test it, and you are going around in circles. [When Claude Code writes the wrong code on a client build](/blog/claude-code-writes-wrong-code-on-a-client-build) covers how to break the loop.
• An outside piece is not cooperating: an integration, an API, a hosting setup, or a usage limit you hit in the middle of the week. [Hitting a rate limit during a client build](/blog/claude-code-rate-limit-during-a-client-build) covers the last one.

If two of these are true at once, the date is at risk. Do not wait to see if a good weekend saves it. Plan the message now, while you still have time to give the client real options.

The Message to Send

Send it in writing, even if you also call. Writing gives the client something to forward to their boss and gives you a record of the new date. Keep it short. A long message reads as an excuse, and a short one reads as someone in control of the work.

Then add the choice, if there is one. 'If Friday matters more than the integration, I can launch without it and add it next week. If you would rather launch everything together, we go live Wednesday. Which works better for you?' A client who chooses the plan is a client who owns the plan with you.

The Options to Put on the Table

Clients handle a slip far better when they get to pick the trade-off. Most missed deadlines leave you with some mix of these four options. Offer the ones that are real for this build, and say plainly which one you would pick and why.

1. Ship less, on time. Launch the parts that are ready on the original date and add the rest after. This is usually the best option when the client has a launch, an event, or a meeting tied to the date.
2. Ship everything, later. Keep the full scope and move the date. This works when the date was internal and nothing outside depends on it.
3. Add help, at a cost the client approves. If you can bring in another builder or pay for a tool that saves the time, say what it costs and let them decide. Never add cost without a yes.
4. Cut scope permanently. Sometimes the slip shows that a feature is not worth what it is costing. Say so, and suggest dropping it or moving it to a later phase with its own price.

Keep money honest in both directions. If the slip is your mistake, do not charge for the extra time it takes to fix it. If the slip came from the client, such as late access or a scope change, it is fair to move the date and to price the extra work with a [change order](/blog/change-order-template-for-a-claude-code-project). If you [structure client payments in milestones](/blog/structure-client-payments-milestones), say whether the milestone payment moves with the date, so nobody is surprised by an invoice.

What Not to Say

• Do not blame the AI. 'Claude got it wrong' tells the client you are not in control of your own tools. You chose the tools, and the work is yours.
• Do not over-explain. Two paragraphs of technical detail reads as an excuse. One sentence of cause is enough, and you can share more if they ask.
• Do not promise a new date you have not checked. Missing the second date is far worse than missing the first. Pad it, then deliver early against it.
• Do not go quiet. Silence is the worst message of all, and it is what turns a small slip into a client who stops trusting you. [What to do when a client goes silent](/blog/what-to-do-when-a-client-goes-silent) covers the other side of that problem.
• Do not hide it in a status update. A missed date buried in paragraph three of a weekly update reads as if you hoped they would not notice. Lead with it.

Stop It Happening on the Next Build

Every slip is a lesson about your process, not your talent. Write down the one cause, then fix it upstream. If the estimate was wrong, change how you [estimate a Claude Code build](/blog/estimate-a-claude-code-build), with a buffer for integrations and client waiting time. If the client found out late, start sending a [weekly client update](/blog/weekly-client-update-prevents-fires) that flags risk before it turns into a slip. If the timeline was never agreed clearly, [set expectations before the build](/blog/set-client-expectations-before-a-claude-code-build), including what happens when the client is the one who is late with access or content.

And if a client asks for a date you already know is tight, say so on day one. A builder who says 'that is possible, but only if we cut this feature or I charge a [rush fee](/blog/charge-a-rush-fee-without-losing-the-client)' is a builder who rarely has to send this message at all.