How to Refund a Client for a Failed AI Build

To refund a client for a failed AI build, do not start from the hours you worked or the total you invoiced. Start from what the client is left holding that has value to them. Hours are your cost, not their benefit, and a refund negotiated on hours will either bankrupt you or insult them, usually both in sequence.

The method below produces a number you can defend in a sentence, which is the only kind worth proposing.

When you owe a client a refund for a failed AI build

Three situations look identical from inside the panic and are not.

The build does not work and cannot be made to work. You owe something. How much depends on what survives, which is the rest of this article.

The build works and the client changed their mind. You owe nothing. A completed deliverable that no longer suits a pivoted business is a scope event, not a failure. Handling scope creep on an AI project covers the version of this that catches it earlier.

The build is late or partial but still viable. Finish it. A refund conversation here is usually the client reaching for leverage on a delivery problem, and the cure is a revised schedule with a milestone attached, not money back.

Only the first case needs a calculation.

Value what they keep, not what you spent

Walk the project and sort everything you produced into three buckets.

Transferable and usable. Working code they can hand to another developer, a populated database, a deployed environment with credentials, a schema, written specifications, design files. This has value to them even though you are leaving.

Transferable but worthless to them. Code that only runs on your machine, experiments, prompt iterations, research you did to get up to speed. Real work, genuine cost, zero resale value.

Nothing to hand over. Meetings, debugging dead ends, time lost to a model that confidently produced a broken approach for two days.

Only the first bucket offsets the refund. That feels harsh when the second bucket was most of the effort, and it is still correct: the client cannot spend your learning curve.

A worked example

A fixed fee of 8,000 for an inventory app. The authentication, the database schema and the deployed staging environment all work. The stock reconciliation engine, which was the actual point of the project, produces wrong numbers and you cannot fix it.

Price each delivered component at what the client would have paid to have just that built, not at the fraction of your time it consumed.

Two details decide whether this holds up. The reporting views are coded and look finished, but they read from the broken engine, so they are worth nothing to the client and you do not get to count them. And the standalone values are what a replacement developer would charge to rebuild each piece, which is checkable, rather than a percentage you picked.

If the client already paid 8,000, you refund 5,500. If they paid 4,000 against milestones, you refund 1,500 and cancel the rest. Structuring payment milestones on an AI project is what makes the second version the normal one.

Hand over everything, then close it in writing

Transfer the repository, the database export, the environment variables and the documentation before the money moves. A refund paid while you still hold the assets invites a second conversation about the assets.

Then write the settlement. Three parts, short, email is fine:

1. What is being refunded and why, in one sentence naming the component that failed. "The stock reconciliation engine did not reach a working state, so I am refunding 5,500 of the 8,000 invoiced."

2. What the client keeps, listed explicitly, with the statement that ownership transfers to them. Name the repository and the database export by filename. If AI-generated code is involved, the ownership position is more complicated than most contracts assume, and who owns AI-generated code sets out the three separate questions hiding in that word.

3. That this concludes the matter. One line: both parties agree the refund settles all claims relating to the project, and neither will seek further payment or damages.

Without the third part you have made a payment, not a settlement, and the client can come back in six weeks with a consequential-loss figure attached.

What this costs you next time

A failed build that ends in a 5,500 refund is a pricing and process failure before it is a technical one. The two changes that prevent the repeat are structural rather than attitudinal: scope the risky component first instead of last, and bill against milestones so the exposure never reaches the full project value. Running a pilot before a full AI build exists for exactly the component that killed this one, and quoting a project when AI does most of the work covers the estimate that got you here.

For the related situation where the work is sound but the client is unhappy about the method, the questions are different and the answer is usually not money.

FAQ

Should I refund the full amount if the main feature failed?

Not if other delivered components genuinely work and transfer to the client. Full refunds make sense when nothing usable survives, or when you breached a contractual term that makes the whole engagement defective.

Can I keep the money if the contract says no refunds?

Less reliably than the clause suggests. In England and Wales, where the client contracted on your written standard terms, section 3 of the Unfair Contract Terms Act 1977 means you cannot rely on a term excluding liability for your own breach unless that term satisfies the reasonableness requirement. Other jurisdictions have their own versions. Enforcing such a clause against a client who received nothing workable also tends to cost more in reputation than it saves in cash.

What if the client wants a refund and the code?

That is the normal outcome, and the calculation above already assumes it. You are refunding the difference between what they paid and what they keep, so they keep it.

Do I have to explain that I used AI tools?

Not as part of the refund. The refund is about a deliverable that did not work, and the tooling that produced it is not the client's concern unless your contract made it one.