Most advice on failed AI projects is written for companies with a steering committee. This page is for the founder who signed off on the spend and now has to decide what happens next.
In brief
- When an AI project fails at a business of 5 to 20 people, the founder has 3 options: salvage the build, restart with a different scope, or stop and close it out.
- AI projects fail in 4 ways, adoption, fit, build, and ownership, and each type has a different default action.
- Three numbers decide what to do when an AI project fails: what the unsolved problem costs per month, what finishing costs from today, and what already exists that has value on its own.
- Money already spent on a failed AI project belongs in none of the 3 numbers, because it is gone whichever option you choose.
- Salvage a failed AI project when finishing costs less than 3 months of the unsolved problem and one named person will own the system afterwards.
- Before shutting anything down, spend 2 hours recovering the process documentation, exported data, prompts and logic, the edge-case list, and every admin credential.
What to do when an AI project fails, in one afternoon
When an AI project fails at a business of 5 to 20 people, the decision in front of the founder is narrow. Salvage the build, restart with a different scope, or stop and close it out.
Getting there takes 2 steps. Name which of the 4 failure types you are looking at, then run 3 numbers. Both fit in an afternoon, and neither requires a board, a steering committee, or an IT department.
The recovery frameworks written for large organisations have the right shape. They ask what the unsolved problem costs, what finishing would cost, and what the existing work is worth. They then assume an executive sponsor, an asset inventory process, and a team to run the analysis. At a 12-person firm the founder approved the spend personally and is now doing the review alone, between client work.
Here is that same test, resized.
The 4 ways an AI project fails, and why the type sets the decision
Start by naming what happened. The word “failed” covers 4 different situations with 4 different default actions.
Adoption failure. The system works. Nobody uses it. The team went back to the spreadsheet in week 3 and nobody told you. Default action is salvage, because the expensive part is already built.
Fit failure. The system works and it automates a step that was not the constraint. Intake got faster while the bottleneck sat in scheduling. Default action is restart with a corrected scope, usually keeping the tooling.
Build failure. The system does not work reliably. Outputs need checking every time, the integration drops records, or it breaks whenever a client sends something unusual. Default action depends on whether the failure is in the tool or in the data feeding it.
Ownership failure. It worked while the consultant was in the building and degraded after they left. Nobody on your team can change a prompt, fix a broken step, or explain what it does. Default action is a short handover project rather than a rebuild.
Most founders describe all 4 as the same thing, which is why the next decision stalls. Write one sentence naming which one you have before you look at any numbers. If 2 apply, take the one that would still be a problem if the other were fixed.
| Failure type | What it looks like | Default action |
|---|---|---|
| Adoption | The system works and nobody uses it | Salvage |
| Fit | The system works on a step that was not the constraint | Restart with a corrected scope, usually keeping the tooling |
| Build | The system does not work reliably | Depends on whether the fault is in the tool or the data feeding it |
| Ownership | It degraded after the consultant left | A short handover project rather than a rebuild |
Telling a failed project apart from a slow one
Some projects that look failed at week 8 are on a normal timeline. Running the salvage test on a project that has not finished yet wastes the review and can kill something that was going to work.
Three signals separate the two.
Look at whether anything written has been produced. A project on a slow but real timeline generates artifacts as it goes, including a findings document, a scoped build plan, and notes from working sessions. A failed project produces meetings and optimism.
Look at whether the scope has changed without a conversation. Quiet scope drift, where the deliverable you discussed in month 1 is described differently in month 3 and nobody flagged the change, means the original plan stopped being followed.
Look at whether your team has touched it. A build that has never been used by the person who will run it is untested, however finished it looks in a demo. Systems that only work in the demo environment are the most common form of false progress.
A project showing all 3 signals has failed, regardless of how much time is left in the contract. A project showing none is slow, and slow usually resolves with a date and a written checkpoint rather than a decision about salvage.
The 3 numbers that decide salvage, restart or stop
Three figures, each of which you can estimate in 20 minutes.
Number 1: what the unsolved problem costs you per month. Take the hours your team spends on the work the project was meant to handle, multiply by a loaded hourly rate, and add any revenue the delay demonstrably costs. Quote turnaround that loses you 1 job a month is a real number. Use conservative figures, because an inflated one talks you into spending more.
Number 2: what finishing costs from today. Get a written figure for the remaining work, whether that is consultant hours, a different vendor, or your own team’s time priced at a real rate. Add 12 months of any subscription the finished system depends on.
Number 3: what already exists that has value on its own. This is the one founders miss. A process map, a documented workflow, a cleaned client data set, a list of the 40 questions your inbox actually receives. That material keeps its value whatever you decide about the software.
Money already spent appears in none of the 3. It is gone in every branch of the decision, so including it only distorts the comparison. This is the single hardest rule to follow and the one that saves the most money.
The salvage test
Salvage when 2 conditions hold at once.
First, number 2 is smaller than 3 months of number 1. If finishing costs $9,000 and the unsolved problem costs $4,000 a month, finishing pays back inside 3 months and the case makes itself.
Second, one named person at your business will own it afterwards. Name the person and write the time into their week. Adoption failures that get salvaged without naming that person fail again within a quarter, which is the pattern behind most of the reasons AI adoption fails in small teams.
An adoption failure usually passes both tests, because the build is done and the remaining work is training, a simpler interface, and a weekly check. That work is cheap relative to what was already spent.
An ownership failure passes if the original consultant will do a documentation and handover pass at a fixed price. Ask for it in writing, with the deliverables named.
The restart test
Restart when the problem in number 1 is real and large, and the build aimed at the wrong step.
The trap is restarting with the same scope and a different vendor. If the diagnosis was wrong the first time, a new build against the same diagnosis produces the same outcome at a second cost.
Before any restart, map where work actually slows down, end to end, with rough timings against each step. Most of the time this is the work that was skipped before the first project started, which is exactly the pattern behind automation that fails because the audit was skipped.
A restart is justified when the map names a different constraint than the one the original project addressed, and number 1 recalculated against that constraint is still large. If the map confirms the original target and the build simply did not work, that is a build failure and belongs in the salvage or stop branch.
When stopping is the right call
Stop when number 1 is small. A problem costing $600 a month does not justify a $15,000 build or the management attention that any system needs after it launches.
Stop when the process the project automates is about to change anyway, because you are switching a core tool, restructuring a team, or moving upmarket.
Stop when the honest answer to “who runs this in 6 months” is nobody. A system with no owner degrades quietly and produces a second failure at a worse time.
Stopping is a legitimate outcome and usually an underused one. The realistic results from AI consulting are uneven by nature, and a business that closes 1 project cleanly to fund a better one is running the portfolio correctly.
What to recover before you shut anything down
Whatever you decide, spend 2 hours extracting the durable material before access lapses. Five things are worth keeping.
- Any process documentation produced during discovery, including the parts that describe how the work runs today.
- Exported data, in a format you can open without the vendor’s software.
- The prompts, rules, and logic built during the project, copied into a document your business owns.
- The list of edge cases the build hit. That list is expensive knowledge and it transfers directly to whatever comes next.
- Admin credentials and the billing owner for every account created, so nothing renews unnoticed.
Subscription accounts set up by a consultant renew on their own. Cancel or transfer each one and write down which you kept and why.
The conversation with the consultant or vendor
Have it in writing, and lead with the artifact rather than the grievance.
Name what the agreement said would exist by now, name what exists, and ask for one of 3 things: the missing deliverable by a stated date, a fixed-price completion quote, or an orderly handover with documentation.
Most reputable consultants will pick one. The response tells you what to do about the relationship, and a written exchange leaves you with a record if the agreement has a remedy clause.
What you should hold at the end of any engagement is covered in what comes after an AI engagement. Use that list as the basis for what you ask for now.
What changes on the next one
Two habits prevent the repeat.
Pick the target by measurement rather than by enthusiasm. The step that costs the most hours per month wins, even when it is unglamorous.
Set a written checkpoint at day 30 with a named artifact attached. A project that has produced nothing written by day 30 has already told you something, and stopping there costs a month instead of a quarter.
If you are deciding whether to bring someone in for the next attempt, the guide to working with an AI consultant sets out what a well-run engagement produces and when the timing is right to start one.
Questions founders ask
Should I keep going with an AI project that isn’t working?
Keep going only if finishing costs less than 3 months of what the unsolved problem costs you, and one named person will own it afterwards. If either fails, restart with a new scope or stop. Don’t let the money you already spent make the call for you.
How much of a failed AI project can be salvaged?
Usually more than founders expect. Process maps, documented workflows, cleaned client data, and the list of edge cases the build hit all keep their value whatever happens to the software. Grab them before the logins lapse.
What should I do if my AI consultant didn’t deliver?
Put it in writing. Name what the agreement said would exist by now, name what exists, and ask for the missing deliverable by a date, a fixed-price completion quote, or an orderly handover. Keep it about the documents, not the frustration.
How do I know if my AI project failed or is just slow?
Check 3 things: whether anything written has been produced, whether the scope changed without a conversation, and whether your team has used it. All 3 showing up means it failed. None means it is slow, and a date plus a written checkpoint usually fixes slow.
Who is responsible when an AI project fails?
The signed agreement decides what the consultant owes. What the agreement cannot cover is the day after handover, when someone inside your business has to own the system. If nobody was named before the build started, the gap is yours to fix, and a short handover project usually closes it. Ask for the missing deliverables in writing before you assign blame.
When should I stop an AI project?
When the problem costs little each month, when the process is about to change anyway, or when nobody will run the system in 6 months. Closing one out cleanly is fine. Letting it limp along for another year is what costs you.
