When a Claude Code Build Runs Over Budget: What to Tell the Client
- Report the overrun the same day you know, in writing, with cause, options, numbers, and a recommendation. Late notice is what damages the relationship, not the overrun.
- Give two or three real options - reduce scope, extend budget, ship a phase one - and say which you recommend and why. A problem without options reads as a demand for more money.
- Keep a Scope Ledger: a running list of every change request with a time cost beside it, shared with the client. Most overruns are visible weeks before they hurt.
Send It the Same Day
The moment you can see the build will exceed the agreed scope or budget, that is the moment to say so. Not at the next weekly call, not once you have tried to make the hours back over a weekend, and not after you have already gone over. The value of the message drops with every day you hold it, because what you are really giving the client is time to make a decision, and time is the thing you are spending while you delay.
Put it in writing rather than raising it on a call. A written message gives them a chance to read it, react privately, and respond with a decision instead of an emotion. If they want to talk it through afterwards, that call goes far better because the facts are already settled.
The Four Parts of the Overrun Message
Every overrun message contains the same four elements in the same order. Keep it short. A long message reads as a defense, and a defense invites a challenge.
- What changed. The specific thing, stated plainly. 'The integration needs to handle three data formats rather than the one we scoped' beats 'the project has grown in complexity.'
- Why, without blame. State the cause factually. If it was a change request, name the request and the date. If you underestimated, say that. Owning your own miss buys enormous credibility for the times it genuinely was a scope change.
- Options with numbers. Two or three real choices, each with a cost and a timeline attached. This is the part people skip, and skipping it turns an update into a request for more money.
- Your recommendation. Say which option you would pick and why. Clients hire builders for judgment. Handing them a menu with no opinion pushes the decision entirely onto someone with less information than you.
| Option | What it means | Best when |
|---|---|---|
| Reduce scope to the original budget | Cut the lowest-value items and ship what was agreed | The added work is genuinely optional and the deadline is fixed |
| Extend the budget for the added work | Approve additional hours at the agreed rate for the specific change | The change is essential to the outcome the client is paying for |
| Ship phase one, quote phase two | Deliver the working core now, scope the rest as a separate engagement | The added work is valuable but not urgent, and a working deliverable now is worth more than a complete one later |
Options to offer - pick two or three, always with a number
The Scope Ledger
Most overruns are not a single dramatic event. They are eleven small requests that each felt too minor to invoice for, and by the time they add up the conversation is awkward because you already said yes to all of them without mentioning a cost. The Scope Ledger removes that entirely.
Keep a running list, shared with the client from day one, of every change request with the date and an estimated time cost beside it. When a new request comes in, add it and reply with the line: added to the ledger, roughly two hours, which puts us at X of the Y we scoped. Nobody has to be confronted, because the number was visible the whole time.
- Log the request the day it arrives, not weekly. Weekly logging becomes a reconstruction exercise and you will undercount.
- Estimate in hours, not in percentages. Hours are concrete and the client can convert them to money themselves.
- Share the ledger where the client already looks - the project doc, the shared folder, the channel you use. A ledger they never see does nothing.
- Add your own misses to it too. A ledger that only contains the client's requests looks like a case being built against them.
When the Overrun Was Your Fault
Sometimes there was no scope change and you simply estimated badly. Say so directly, absorb the portion that is genuinely your miss, and be specific about where the line sits. 'The auth work took twice what I quoted, that one is on me and I am not billing for it. The three-format requirement from the 4th is separate and that is the piece I need a decision on.'
Splitting it explicitly is what makes it credible. A builder who absorbs everything looks like they cannot estimate, and a builder who bills for everything looks like they are farming change requests. Naming which part is yours proves you are tracking the difference honestly, and that is the thing clients pay a premium for on the next project.
Set the Ledger Up on Your Current Build
Open the project doc for whatever you are building right now and add a change log table with three columns: date, request, estimated hours. Backfill everything you can remember, share the link with the client with one sentence explaining what it is, and log every request the day it arrives from here on. It takes 15 minutes and it converts the hardest conversation in client work into a routine status line.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What do I tell a client when a project goes over budget?
Tell them the same day you know, in writing, with four things: what specifically changed, why without assigning blame, two or three options each with a cost and timeline attached, and which option you recommend. The options are the part that turns bad news into a decision they can make rather than a demand for more money.
Should I absorb the extra cost instead of telling the client?
Only for the portion that is genuinely your estimation miss, and say so explicitly when you do. Silently absorbing everything teaches the client nothing about what their change requests cost, so the same overrun repeats on the next project and you carry resentment into a relationship that should be profitable.
How do I stop client projects from going over budget in the first place?
Keep a shared change log from day one with every request dated and estimated in hours. Overruns are usually a series of small requests nobody priced, and a visible running total makes the cost obvious in real time instead of a confrontation at the end.
What if the client refuses to pay for the extra work?
That is why the message includes a reduce-scope option. If they will not extend the budget, you cut the lowest-value items and ship what was originally agreed. The decision stays theirs, the original agreement is honored, and neither side is asked to eat work they did not sign up for.
Last reviewed August 12, 2026.
Co-founder of the Claude Code Profit Room. Went from shipping software to closing paying clients, and now teaches builders the selling half of the equation.
More from David Iya →
