When a Client Blames Your Build for a Problem It Didn't Cause
- When something breaks near your build, the client will often assume your build caused it. That is normal, not an attack. Your job is to stay calm, check honestly, and find the real cause before anyone argues about fault.
- Use the Profit Room's Evidence First method: acknowledge fast, investigate before you defend, show what you found in plain language with proof, fix anything that is genuinely yours for free, and offer help with the real cause as a separate, priced piece of work.
- Prevent it next time. Write down what your build does and does not touch, log what it does, and agree before launch how problems get reported and diagnosed, so the next 'your thing broke it' conversation starts with facts.
The Short Answer
When a client blames your build for a problem it didn't cause, reply quickly, take the problem seriously, and check before you defend yourself. Sometimes it is your build, and you want to find that out before the client does. If the evidence shows the cause is somewhere else - a changed setting, another tool, an expired login, a vendor outage - show them what you found in plain language, help them get to the real fix, and keep the relationship intact. Fix anything that is yours for free. Treat work on the real cause as new work with a price.
That is the Evidence First method. It matters because how you handle blame decides whether the client trusts you more or less afterward. Arguing makes you look defensive. Fixing someone else's problem for free in silence teaches the client your build is fragile. Showing calm, clear evidence makes you the person they call next time something breaks. It is close to handling [when a client finds a bug after launch](/blog/client-finds-a-bug-after-launch), with one difference: this time you are not sure the bug is yours.
Why Clients Blame the Build
It is rarely personal. Your build is the newest, most visible thing in their business, so it is the first suspect.
- Timing. Something broke after your build launched, so the build looks like the cause, even if the two are unrelated.
- Visibility. Your build is where the problem shows up. If a booking assistant cannot see the calendar, the client sees the assistant fail, not the calendar connection that changed.
- Someone changed something. A team member updated a setting, a password expired, or another vendor changed their tool, and nobody connected that change to the problem.
- Another tool failed. A service your build depends on had an outage or changed how it works.
- Pressure. The client has a customer or a boss upset about the problem, and they need an answer fast.
None of these mean the client is being unfair. They mean the client needs help finding the cause, and you are the person best placed to find it.
Run the Evidence First Method
Use these steps the moment a client says your build caused a problem.
- Acknowledge within the hour. Thank them for flagging it, say you are looking into it, and give a time for your next update. Do not diagnose yet, and do not say 'that is not my build'.
- Get the specifics. Ask what happened, when, to whom, and what they expected instead. A screenshot or an exact error message is worth more than a long description.
- Check your own build first, honestly. Look at your logs, your recent changes, and what the build did at the time of the problem. If you find a defect, say so and fix it. Owning a real mistake fast is what makes your word count when it is not yours.
- Trace the real cause. If your build behaved as designed, follow the problem outward: connected accounts, permissions, settings that changed, other tools, vendor status pages. Claude Code can help here. With the client's permission, it can read through logs you have access to and help you trace where a flow broke. You still decide what the evidence shows.
- Show, do not argue. Send a short summary: what happened, what caused it, the proof, and what fixes it. Keep it factual and blame-free.
What to Fix Free and What to Charge For
Be generous with anything that is yours and with the diagnosis itself. Be fair about everything else.
| What you find | Who owns it | What to do |
|---|---|---|
| Your build has a defect | You | Fix it free, quickly, and say so plainly |
| Your build should have handled the failure more gracefully | You | Improve the error handling free if it was in scope |
| A setting, login, or permission changed on their side | Client | Show the evidence and walk them through the fix |
| Another vendor's tool changed or failed | Vendor | Point to the cause; offer to adapt your build as paid work if needed |
| They want your build to handle this case in future | Client | Send a change order |
Sorting a blamed problem
If you are past the support window, the diagnosis itself may be paid work. [When a client wants free help after the project ends](/blog/client-wants-free-help-after-the-project-ends) covers where that line sits. Many builders still do a quick first check for free, because finding out fast whether it is your build protects your reputation either way.
Set Up Builds That Are Easy to Defend
The best defense is a build that makes the cause obvious.
- Write down the boundaries. Your [scope of work](/blog/scope-of-work-that-prevents-scope-creep) should say what the build does, which accounts and tools it connects to, and what it depends on that you do not control.
- Log what the build does. Simple logs of what it tried, when, and what came back turn a blame conversation into a five-minute check.
- Fail clearly. When a connected tool stops responding, the build should show or send a clear message about which connection failed, instead of failing silently.
- Agree how problems get reported. Before launch, tell the client what to send you when something looks wrong: what happened, when, and a screenshot.
- Keep them informed. A [weekly client update](/blog/weekly-client-update-prevents-fires) during the first month surfaces small issues before they become blame.
- Offer ongoing support. A [maintenance plan](/blog/package-a-maintenance-plan-for-ai-builds) makes diagnosis a normal, paid part of the relationship instead of an argument.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What should I do when a client blames my build for a problem?
Reply quickly, take it seriously, and check your own build first. If it is yours, fix it free and say so. If the evidence points elsewhere, show the client what you found in plain language, with proof, and help them get to the real fix.
How do I tell a client the problem isn't my build without sounding defensive?
Lead with what you checked and what you found, not with whose fault it is. Share the evidence, name the likely cause without accusing anyone, and offer the next step. Facts and a helpful tone do the persuading for you.
Should I fix a problem my build didn't cause for free?
Diagnosing it quickly is often worth doing free, because it protects your reputation. Fixing the real cause, or changing your build to handle a new situation, is new work with a price. Quietly patching around someone else's problem usually means it breaks again.
Can Claude Code help find the real cause of a client's problem?
Yes. With the client's permission, Claude Code can read through logs and error reports you have access to and help you trace where a flow broke. You still review the evidence and decide what to tell the client.
How do I stop clients blaming my builds in future?
Write down what the build does and depends on, log what it does, make it fail with clear messages, agree how problems get reported, and offer a maintenance plan so diagnosis is a normal part of working together.
Last reviewed October 21, 2026.
Co-founder of the Claude Code Profit Room. Built and sold AI services to real clients; writes about offers, pricing, outreach, and closing with receipts.
More from Duncan Rogoff →