Your Client's AI App Got a Bad Review: What Next

Your client's AI app got a bad review, and they have forwarded you the one-star. Before you answer the email, work out which of three things you are looking at: a defect, a mismatch between what the app promises and what it does, or a user who wanted a different product. Each one has a different owner, and the mistake that costs money is treating all three as your problem.

Here is how to sort it, and how to talk about it without either grovelling or getting defensive.

First, resist the reflex to fix

The reflex when a client forwards a bad review is to open the editor. Do not. You have not established what is wrong yet, and a fix shipped inside an hour of an angry forward is how a one-star review becomes an unpaid week.

The useful first move is slower and takes fifteen minutes: reproduce it. Find the account, find the session, follow the steps in the review. Until you can make the thing happen, you are guessing.

Roughly half the time you cannot reproduce it, and that is itself the finding.

Sort the review into one of three buckets

Bucket one: a defect

The app does something it was specified to do, and it does it wrong. Crashes, wrong totals, failed payments, data loss.

This is yours. Fix it, and if your contract has a warranty or defect period, say so plainly and do not invoice. Arguing about whether a crash is in scope is more expensive than the crash.

Bucket two: an expectation mismatch

The app does what it was built to do, and the user expected something else. The listing implies offline support that was never built. The onboarding suggests the import handles Excel when it handles CSV. Nothing is broken. The promise and the product disagree.

This is shared. The copy, the screenshots and the store listing are usually the client's, and the behaviour is yours. The fix is often a wording change rather than code, which is good news for everyone, and it is worth saying so early because clients assume mismatch means rebuild.

Bucket three: a different product

The user wanted features that were deliberately not built. Someone reviews a simple booking tool one star because it does not do inventory.

This is nobody's defect. It is a positioning problem, and it belongs to whoever decides what the app is for. Your job here is to say that clearly and not let it turn into free scope, which is the exact mechanism described in handling scope creep on an AI project.

The specific risk with AI-built apps

Apps assembled quickly with AI fail in a particular way: breadth without depth. The happy path works, and the edges were never considered because nobody wrote them down to be considered.

So the reviews cluster around things that are not quite bugs. The app works until a name has an apostrophe in it. It works until someone uses it on a slow connection. It works until the 51st record. Each of these reads to a user as "this is broken" and to a developer as "that case was not in scope", and both are right.

The honest framing for a client is that a fast build buys reach and defers edges, and that bad reviews after launch are substantially how you learn which edges were load-bearing. That is a reasonable trade if everyone agreed to it. If nobody said it out loud at the start, you are having the conversation now, under pressure.

Say it early next time. Running a discovery call for an AI project is where that expectation gets set.

What to send the client

Keep it to four things, in this order:

1. What you found. Reproduced or not, and the specific steps if you did.

2. Which bucket. Defect, mismatch, or different product. Name it.

3. Who owns it, and the cost. "This is a defect, covered, fixing today." Or: "This is a listing mismatch, I can change the app or you can change the copy, the copy is cheaper."

4. One thing to prevent the next one. A test around the broken case, an error message that explains the limit, a line in the listing.

That last item is what turns an uncomfortable email into a reason to keep you. The client did not hire you to be blameless, they hired you to make the app better than it was last month.

What not to send: a defence of the architecture, a note about how AI wrote that part, or a quote attached to the first reply. The quote comes after the bucket is agreed.

When the review is about a decision the client made

Occasionally the review is about something you advised against and the client chose anyway. The cheap offer is to say so. Do not take it.

Reference your record if it exists, neutrally and once. "This is the import limit we discussed in March, here is the note." Then move to what to do now. A client who feels blamed in front of their own bad review will remember the blame and not the fix. If the pattern repeats across several decisions, that is a relationship conversation to have separately, not in the thread about a review.

If you need to say no to the remedy they propose, telling a client their AI project idea will not work covers how to do it without damage. And if reviews are arriving steadily, they are a roadmap input rather than a crisis, which is the approach in turning customer reviews into a feature roadmap.

FAQ

Should I fix a bug reported in a review for free?

If it is a genuine defect in specified behaviour and you are inside any warranty period you agreed, yes, and say so without being asked. If it is an edge case that was explicitly out of scope, it is chargeable work, but price it as a small change rather than a project.

Who should reply to the review itself?

The client, not you. It is their business relationship and their public voice, and on most platforms the reply is posted under the business name. Google, for instance, screens Business Profile replies against its content policies before they appear. You can draft the technical content of the reply if they want it, but the reply should come from the business.

What if the review mentions that the app was built with AI?

Treat it as noise. Users describe any app that frustrates them in the language available to them. The bucket the complaint falls into has not changed, and defending the build method in public reads worse than the original review.

How do I stop this from recurring?

Write down what the app does not do, before launch, in the same document as what it does. Most expectation mismatches are a listing that outran the build, and a short out-of-scope list in the handover prevents a surprising number of them.