Ask for a quote on an AI project and you will get a number built from engineering days. So many weeks to build it, some contingency, a rate. The shape of the quote says the risk lives in the construction.
It does not, and there is reasonable evidence about where it does live. The distinction matters, because it changes what a proposal should contain and how you should judge one.
What the failures were actually caused by
The most-quoted research on this is the July 2025 paper from researchers at MIT’s Project NANDA. It is the source of the 95% statistic, and we have written separately about what it actually measured, because the popular version distorts it.
One line from it matters more than the famous number:
This divide does not seem to be driven by model quality or regulation, but seems to be determined by approach.
Not the models. Not compliance. Approach, which is a polite word for how the organisation went about it.
The same paper contains a finding that makes the point harder to argue with. While only 40% of the companies surveyed had bought an official LLM subscription, workers at over 90% of them were using personal AI tools for their job, and the report says this unofficial usage “often delivers better ROI than formal initiatives”.
Sit with that for a second. The technology was already working inside those businesses. People had found it themselves, without a budget, without a procurement process and without a supplier. What failed was the programme wrapped around it.
Why the quote is the wrong shape
Two things have moved in opposite directions.
Building software has got dramatically faster over the past three years, and the direction of travel is not subtle. A competent engineer with current tooling produces in days what used to take weeks. That is not a claim about quality. It is a claim about pace, and anyone who has watched the change knows the scale of it.
The other half has not moved at all. Working out which process is worth changing takes the same time it always did. So does establishing what that process currently costs, deciding whose job changes, getting the person who owns the old way to agree to stop, and being around when it does not go smoothly in week three.
So the estimable part is shrinking and the risky part is not. A quote built from engineering days is measuring the half that behaves predictably, and it will keep getting more wrong.
What the expensive part consists of
Four things, and none of them is code.
Choosing what to change. Most processes in most businesses are not worth automating. Too low volume, too much judgement, too risky, or already fine. Deciding not to build something is a real output, and it is the most valuable decision available. A supplier who has never talked a client out of a project has probably not been looking very hard.
Establishing what it costs today. How many hours, how often it goes wrong, how long the turnaround is. Most businesses cannot answer this about their own operations, which is why so many projects end in an argument about impressions rather than a comparison. The number has to be captured before anything is built, because afterwards everyone’s memory has been coloured by the project.
Deciding whose job changes. This is the one that quietly kills working systems. The person who currently does the task manually is the person who has to stop, and they usually did not ask for any of this. If nobody has changed what they are measured on, the old process survives, running in parallel, forever.
Being there after it goes live. The awkward cases arrive in week two. The person who championed it moves teams. Something upstream changes and the thing quietly stops working. A project that ends at handover is a project that ends before the part where value appears.
The objection
If building is faster now, what exactly am I paying you for?
Fair question, and the honest answer is that you are not paying for the hours. You are paying for the decisions that make the hours worth spending, and for somebody being accountable when the system meets the business and the business pushes back.
There is a version of this that should make you suspicious, so name it before a supplier does. “The strategy is the valuable part” is also what a consultancy says when it does not want to build anything and would rather sell you a document. The test is whether the same people who make the decisions also ship the system and stay attached to it afterwards. Advice that leaves before the build has not been tested against anything.
How to read a proposal after this
Four things to look for, and they take a minute.
Does it name the process, or the technology? A proposal that leads with the stack has decided what to build before understanding what is wrong. The technology choice is usually the least consequential decision in the project.
Does it record a starting number? If nobody writes down what the current process costs, nobody can tell you afterwards whether it worked. That is not a measurement failure at the end. It is a scoping failure at the beginning.
Does it say who stops doing what? Silence here is the strongest predictor of a system that works and sits unused. If the proposal does not name a person whose week changes, nobody has thought about adoption.
Does it cover the first three months after go-live? Not a support contract for outages. Somebody accountable for whether the thing is actually being used, with the authority to change it when it is not.
And one to ask out loud: what would make you tell us not to do this? A supplier who cannot answer is selling a build.
The uncomfortable part for suppliers
This argument makes projects smaller. It moves money out of the line item that is easy to justify on a timesheet and into work that is harder to price and harder to demonstrate in a meeting. It also means telling clients that half of what they were about to buy is unnecessary.
That is a poor sales strategy in the short term, and it is why the market keeps pricing the build. The quote is shaped that way because it is the shape everyone recognises, not because it reflects where projects go wrong.
The industry’s own money is moving the other way. The largest firms in AI have spent the past year putting serious capital behind deployment rather than research, which we looked at in where the AI implementation money went. They are not investing in delivery because building has become harder.
What this means if you are buying
Spend less on the build than the market will quote you, and considerably more attention on everything around it.
Pick one process, and pick it because you can state what it costs you today. Agree what the finished thing has to score before anyone writes code, which we set out in the definition of done. Name the person whose job changes and get them into the room early rather than presenting to them at the end. Then keep somebody accountable for the three months after launch, because that is when it either becomes how the work gets done or quietly becomes an optional extra nobody uses.
The software will be the most predictable part of it. That is the good news, and it is also the part most quotes are still built around.
Frequently asked questions
Why is the build the most predictable part of an AI project?
Because building software has become significantly faster with current tooling, so it is the part that can be scoped and estimated. The organisational work around it has not changed at all. Deciding what to change, measuring what it costs today, and getting people to work differently take the same effort they always did.
What actually causes AI projects to fail?
The July 2025 Project NANDA research put it down to approach rather than technology, stating that the divide “does not seem to be driven by model quality or regulation”. The same study found workers at over 90% of surveyed companies using personal AI tools successfully while formal programmes struggled.
If building is faster now, what am I paying a supplier for?
The decisions that make the build worth doing, and accountability after it ships. Be wary of anyone who uses this argument to sell advice without building anything, since strategy that never meets production has not been tested.
How do I tell a good AI proposal from a weak one?
Look for a named process rather than a named technology, a recorded starting number, an explicit statement of whose job changes, and coverage of the first three months after launch. A proposal missing all four has been priced for construction alone.
What is the most common reason a working AI system goes unused?
Nobody’s objectives changed. The person who did the task manually was never given a reason to stop, so the old process keeps running alongside the new one until the new one is quietly abandoned.
Flux Dynamics is a fractional CTO who builds. We spend most of a project deciding what is worth building and making sure it gets used, because the code was never the risky part. Tell us what you are considering.