A Client Found a Bug After Launch: What to Say and What to Charge

The Short Answer

When a client reports a bug after launch, reply quickly, confirm you are looking at it, and then decide one thing before you quote anything: is this broken or is it different. If the thing you delivered does not do what you both agreed it would do, fix it at no charge and quietly. If it works as agreed and the client now wants it to do something else, that is a change request and it gets a price. Say which one it is in plain words, and give the next step in the same message.

Why the First Message Always Feels Worse Than It Is

A client reporting a bug is usually not angry. They are worried, and worry reads as blunt in writing. They spent money on something and the thing did not behave, so their first message is short, has no context, and often arrives with an exclamation mark. Reading it as an attack is the single most expensive misreading in client work, because the reply you write to an attack is defensive and the client can hear it.

There is also a version of this that has nothing to do with your code. Someone changed a password, a third-party service had an outage, an integration expired, or a staff member used the tool in a way nobody described. From the outside all of it looks identical: the thing you built stopped working. That is why the first reply confirms you are looking rather than accepting fault or denying it.

The First Reply, In Full

The first reply has three jobs and takes two minutes: acknowledge, commit to a time, and ask for one specific thing you need. It does not diagnose, promise a fix, or mention money. You are buying yourself the space to find out what actually happened without the client sitting in silence imagining the worst.

1. Acknowledge without agreeing it is a defect. 'Thanks for flagging, I am on it' is enough. You have not conceded anything and the client has stopped worrying.
2. Commit to a time for the next update, not for the fix. 'I will come back to you by 4pm with what I have found' is a promise you can keep even if the problem turns out to be complicated.
3. Ask for one thing that makes diagnosis possible. A screenshot, the exact time it happened, or which user hit it. Ask for one, not five, because a list of questions reads as friction.
4. Do the diagnosis before you say anything about cost. Once a number is in the conversation the client hears everything after it as a negotiation.

Broken Versus Different - The Only Distinction That Matters

Every post-launch report resolves into one of three buckets, and the bucket determines both the money and the tone. Get this wrong in either direction and it costs you: charging for a genuine defect burns the relationship, and absorbing every change request turns you into unpaid staff for a project that already closed.

The wording that keeps this friendly is to name the bucket without making the client wrong. 'This one is on me, it is fixed' for a defect. 'This is doing what we set it up to do, and what you are describing is a genuinely useful addition, so let me price it as a small piece of work' for a change. Both sentences are calm, both are honest, and neither one argues.

The Free Window, and Why You Should Have Said It Already

The reason this conversation is stressful is almost always that nobody agreed what happens after launch. Fix that once, in writing, at the start of every project: a defect window of a stated length during which anything genuinely broken gets fixed at no cost, and everything else quoted separately. Thirty days is a normal window and easy to defend. The exact number matters far less than having stated one.

• Put the window in the agreement, not in an email later. A term introduced after a bug report reads as a reaction to the bug report.
• Say what it covers in one sentence: work that does not match what we agreed. That single phrase does almost all the classification for you afterwards.
• Say what it excludes: new requests, third-party changes, and anything caused by a change on their side. Naming these in advance means you are not inventing exclusions under pressure.
• Say what happens after the window: a support arrangement, or work quoted as it comes. Giving the client a choice makes the end of the window feel like an option rather than a cutoff.

How to Charge for a Change Without Sounding Like You Are Nickel and Diming

The trick is to price the change as a small piece of work with a name, not as an hourly add-on to a finished project. 'That is two hours at my rate' invites the client to argue about the hours. 'I can add that as a small piece of work, here is the number, and it would be done Thursday' gives them a decision with a shape.

One more thing makes this land cleanly. Offer to do the smallest genuinely broken part free even when the rest is a change. If the report contains one real defect and three new requests, fix the defect immediately, say you have done it, and then price the three. The client sees good faith before they see a number, and the number stops feeling like an opportunistic response to their problem.

Turn the Moment Into a Support Arrangement

A post-launch bug is the best possible moment to sell ongoing support, because the client has just felt the specific fear that support removes. Do not pitch it in the same message as the fix. Fix the thing, let them see it working, and raise it a few days later while the memory is fresh but the panic has gone.

The framing that works is availability rather than maintenance. Clients do not want to buy the possibility of future bugs. They want to know that when something stops, someone answers. A monthly arrangement described as a response commitment plus a small allowance of changes is easy to say yes to, and it converts the exact anxiety they just experienced into something they can pay to stop feeling.