We turn down a meaningful share of the AI work we are asked to do. Not because it is hard, but because it would not have paid for itself, and discovering that after six months is far more expensive than discovering it in week one.
Lacewing Technologies is an AI and software development company in Navi Mumbai, and the pattern below is drawn from projects we have run, projects we have declined, and a fair number we have been called in to rescue after someone else built them.
What does a failed AI project actually look like?#
Not a crash. That is the surprising part.
The failed projects we get called into are usually working. The model responds, the integration holds, the dashboard loads. What is missing is usage. Six months in there is a functioning system that three people opened once, because the thing it automated took two hours a week and everybody had already found a way to live with those two hours.
Nobody logged a defect, because there is no defect. The software does what was asked. The asking was the problem.
Why does the wrong process get chosen?#
Because the selection criterion is usually visibility rather than cost.
A business hears it should be doing something with AI. The conversation happens at a level where the most legible processes are the customer-facing ones, so somebody proposes the customer-facing one. It demos well. It gets approved. Meanwhile the actual money is going out through a back-office process that nobody in the room does personally and therefore nobody in the room proposed.
The second driver is competitor announcements. A competitor publicises a chatbot, so a chatbot goes on the roadmap, without anyone establishing whether the competitor's chatbot worked or whether their enquiry mix resembled yours at all.
Neither of these is stupidity. Both are what happens when a decision gets made without a number attached to it.
What are the four tests that predict success?#
These are the questions we ask in the first meeting. A process that clears all four is usually worth automating. A process that fails one is worth a longer conversation, and a process that fails two is usually worth declining.
| Test | Why it matters | Warning sign |
|---|---|---|
| Runs many times a day | Volume is what converts a small per-item saving into real money | "A few times a month" |
| Done consistently by a person today | If humans do it three different ways, there is no process to automate yet | Every branch does it differently |
| Has a number attached | Without a baseline you cannot prove value, so the project gets judged on vibes | Nobody can say what it costs today |
| Someone owns the output after go-live | Unowned output becomes an unread queue | "We'll figure that out later" |
The frequency test does most of the filtering. Automating something that runs 200 times a day at two minutes each is 400 minutes a day of recovered capacity. The same automation on something that runs twice a week is a rounding error, however impressive the technology.
The ownership test does the rest. It is the one people wave away in the first meeting and the one that kills the most projects afterwards. Every automation produces something: a queue of exceptions, a set of flagged documents, a list of qualified leads. If no named person is responsible for acting on that output, it accumulates silently until somebody declares the system broken.
Why is the baseline number the hardest part?#
Because almost nobody has it, and gathering it feels like a delay before the interesting work starts.
Ask a business what its current invoice processing costs and you will usually get an estimate that is wrong by a factor of two in either direction. Not through carelessness. The cost is distributed across three people who each do a bit of it, plus the accountant who fixes it at month end, plus the occasional payment that goes out late because someone missed a bill.
Spending a week establishing that number does two things. It tells you whether the project is worth doing at all. And it gives you the only defensible way to answer the question you will be asked at the end, which is whether it worked.
Projects without a baseline get judged on impressions, and impressions are set by whoever complains loudest about the transition.
What about projects that work technically and fail anyway?#
This is the second-largest category, and it has nothing to do with the software.
An automation changes who does what. The person who used to do the task by hand now checks the machine's output, which is a different job, often a less interesting one, and occasionally one they read as a demotion. If that conversation has not happened before go-live, it happens afterwards in the form of quiet non-adoption: exceptions left in the queue, corrections not made, a parallel spreadsheet maintained on the side because the old way still feels safer.
Three things prevent most of it.
Tell people what the automation is for before it arrives. Framing matters. "This removes the retyping so you can chase the disputed bills" lands very differently from an announcement that a process is now automated.
Give the reviewing role to someone senior enough to overrule the system. A reviewer who cannot reject the machine's output is doing data entry with extra steps, and will treat it that way.
Run in parallel long enough to build trust. Two to four weeks of the automation running alongside the manual process, with the outputs compared, is the cheapest confidence you will ever buy. It also catches the edge cases that no specification predicted.
None of this is in the technical scope, and all of it decides whether the technical scope was worth building.
What does the cheap version of finding out look like?#
A short audit of what people actually do all day, ending in a costed shortlist.
Ours runs about two weeks and produces a ranked list of candidate processes, each with an estimated current annual cost, an estimated build cost, an estimated running cost, and a recommendation. Roughly half the time the top recommendation is not an AI build at all. It is a process change, a form redesign, or admitting that the spreadsheet was fine and the real problem is that two teams keep separate copies of it.
Clients own that document outright. They can take it to any supplier, including one that is not us, and several have. That is not generosity. A costed shortlist that survives being shown to a competitor is the strongest evidence that the recommendation was honest.
The pattern worth remembering#
Start with the process that costs the most and is done the most consistently. Build the smallest version that touches real data and real users. Measure against a number you wrote down before you started. Widen only if it moved.
The technology has not been the constraint for a while now. Choosing the right thing to point it at still is.