How to say no to an AI project that will not work
6 minute read. Updated 2026-08-08.
Refuse an AI project when there is no agreed measure of success, the data does not exist yet, or the client has already decided the answer. A failed engagement costs a finite fee; the reputational damage of shipping it does not stop there, because reference calls happen for years. Describe the consequence of proceeding rather than call the client's plan wrong, and offer a smaller, paid diagnostic instead of a flat no.
Why saying yes is the expensive option
A contract you take and fail costs more than a contract you never took. The fee for a doomed engagement is finite, a day rate, a number of weeks, an invoice that stops the day the client pulls the plug. The cost of being associated with a system that never worked follows you into every reference call after.
Fractional AI work runs on referral. Reference calls happen quietly and they happen for years. Nobody phones ten people before hiring; they phone two or three, and one bad answer from a former client outweighs a strong CV. Saying yes to a project you know will not work protects one relationship for a few months and puts several future ones at risk.
What a project that will not work looks like
Not every hard project should be refused. Refuse the ones with a specific shape: no agreed way to measure success, a deadline set by someone who has never trained a model, data that does not exist yet in the form the project assumes it does, or a stakeholder who has already decided the answer and wants a model that confirms it.
A concrete example: a head of operations wants a chatbot live in three weeks, answering questions from a document library that has not been written yet. The timeline is not the real problem. The missing library is. No amount of prompt engineering fixes a knowledge base that does not exist.
The commercial case for refusing
Work out what you are actually being offered before you decide whether to protect it. At the median advertised day rate for AI work, £551, a 10-week engagement at three days a week is 30 days: £16,530 before tax, before any deductions if the engagement sits inside IR35. That is a real number, and walking away from it is a real cost.
Set against it: doomed projects rarely run their full term anyway. They tend to collapse two-thirds of the way through, once the sponsor realises the demo will not survive contact with real data, and by then you have absorbed weeks of unpaid dispute, rewritten scope documents and difficult conversations that a clean refusal at the start would have avoided entirely.
The reputational case for refusing
When an AI system fails, the failure gets attributed to the person who built it, not to the business decision that made failure inevitable. Nobody in the post-mortem says the deadline was unrealistic or the data never existed. They say the model did not work, and your name is on the model.
The specialist market is small enough that this matters more than it would inside a large agency. Your reputation is not diluted across dozens of colleagues. It is entirely yours, and a single well-known failure sits on it for longer than the contract that caused it ever ran.
How to say it without losing the relationship
The aim is not to tell the client their plan was wrong. It is to describe what will actually happen if the plan goes ahead, and let the client draw the conclusion. Try: I can build what you're describing, but here's what happens when it meets real data. It will confidently give the wrong answer, and nobody will notice until a customer does.
On timeline: the three-week version gets you a demo for the board. It will not survive contact with real users. I can give you a working demo on that timeline, or a working system on a longer one, not both, and I would rather tell you that now than in week two.
On scope: this problem does not need a model. It needs a rule and a spreadsheet, and I would be overcharging you if I sold you the model version.
What to offer instead of a flat no
A refusal lands better with an alternative attached. Offer a smaller, paid diagnostic: a week assessing whether the data exists in usable form, or a fixed-scope proof that tests the riskiest assumption before either of you commits to the full build.
This keeps the relationship and the fee, turns an argument into a piece of paid work, and gives the client a genuine answer instead of a demonstration built to survive one meeting. If the diagnostic proves the project workable after all, you are already the person who did the honest first step, and you are first in line for the build that follows.
What to do about it
- Refuse projects with no agreed measure of success, missing data, or a predetermined answer already decided by the client.
- Work out the value of the contract you are refusing, then weigh it against the reputational cost of shipping a failure.
- Describe the consequence of proceeding rather than telling the client their plan is wrong.
- Offer a smaller, paid diagnostic in place of a flat refusal wherever the relationship is worth keeping.
- Expect a doomed project to collapse two-thirds of the way through rather than at the start; refusing early avoids absorbing that time unpaid.
Questions people also ask
What if the client insists on going ahead after I've explained the risk?
Reduce the scope rather than walk away outright, if the relationship is worth keeping. Agree a fixed, smaller piece of work with an explicit measure of success, put your warning about the wider risk in writing beforehand, and let the client decide with that on record. If it fails, you have documented that you flagged it and scoped around it. If it succeeds, you are still the one who delivered it. What you should not do is deliver the full, unscoped version you already believe will not work.
Won't refusing the work damage the relationship anyway?
Less than delivering a failure does. A client who hears a clear, specific reason why something will not work, along with an alternative, usually respects the honesty and comes back for the next piece of work. A client who watches a system fail in front of their own customers rarely calls again, and tells other people why. The relationship survives a well-argued no far better than it survives a shipped failure.
How do I tell if a project is fixable rather than fundamentally broken?
Ask two questions. Does the data the project depends on actually exist in a usable form today, not in six months? And can anyone on the client side describe, in a sentence, what success looks like and how it will be measured? If both answers are yes, the project is probably fixable with the right scope. If either answer is no, the project needs a different shape before it needs an engineer.
Should I put my refusal in writing?
Yes, always. An email that sets out what you were asked to build, why it will not work as scoped, and what you are proposing instead protects you if the client goes elsewhere and the project fails as predicted. It also gives the client something concrete to react to, rather than a vague conversation they can misremember later. Verbal warnings get forgotten. Written ones do not.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.