
Why AI Consultation Is Important for SaaS Companies
A model arrives knowing an enormous amount about the world and nothing about your company. Here is what the research says actually goes wrong with AI projects — and why almost none of it is the model's fault.
- ai strategy
- saas
- ai readiness
Picture a software company that has just decided to add an AI feature. The engineers are good. The model is one of the best available. The demo in the sprint review gets a round of applause. Eight months later, the feature is quietly switched off.
This happens constantly, and it is worth understanding why — because the reason is almost never the thing people blame.
Start with what the research found
Several large studies have now looked at this, and they disagree about almost nothing.
MIT's Project NANDA reviewed more than 300 enterprise AI deployments and found that roughly 95% of generative AI pilots produced no measurable profit impact, against $30–40 billion of spending. Gartner predicted that at least 30% of these projects would be abandoned after the trial stage, and listed the causes: poor data quality, weak risk controls, rising costs, unclear business value. S&P Global surveyed over 1,000 companies and found 42% had abandoned most of their AI work in 2025, up from 17% a year earlier.
Now read those causes again. Not one of them says the model was not clever enough.
A way to think about it that actually helps
Here is the analogy I would give you.
A model arrives knowing an enormous amount about the world and nothing whatsoever about your company. It is a brilliant new graduate on their first morning: quick, capable, and completely unable to do the job yet. Not because they lack ability — because three things are missing.
- They do not know your data. And some of what you have is stale, incomplete, or quietly wrong in ways nobody has checked.
- They cannot get into the systems that hold it. That needs owners, permissions and sign-offs, and nobody has started asking.
- Nobody has said who checks their work. When the output is wrong — and it will be — there is no name attached to catching it.
Every one of those is an organisational problem wearing a technical costume. And notice what none of them respond to: a smarter model. That is the whole insight. Informatica asked 600 data leaders about this directly — 57% named data reliability as a top barrier, and three in four admitted their governance had not kept up with their own AI adoption.
Why software companies feel this harder
Three reasons, specific to SaaS.
Your mistakes happen in front of someone else's customer. An internal tool that invents an answer embarrasses you in a meeting. A shipped feature that does it does so under your logo, in your customer's product, with your contract behind it.
AI changes your economics, not just your roadmap. Software used to be sold per user, per month — predictable revenue, near-zero cost to serve one more person. AI breaks that, because every use costs real money in compute. Pricing is moving to match: hybrid models, a base fee plus charges for actual usage, are now the most common structure in B2B software at 37%. A feature can work perfectly and still lose money on every call.
Using AI is not the same as benefiting from it. McKinsey's 2025 survey found 88% of organisations using AI somewhere, but only 39% able to point to any effect on profit, and around 6% doing genuinely well with it. What set that 6% apart was not better models. It was redesigning how the work happened around the tool.
Find out where you actually stand
An AI Readiness check scores your data against what a real build would demand, names the access and ownership gaps, and tells you what has to be true before the first line of code. Ready, not ready, or not yet — in writing.
So what does a consultant actually do?
Not build it for you. Answer three questions while answering them is still cheap.
Is the groundwork there? Whether your data, your access paths and your people clear the bar this specific project sets — asked while a gap is still a decision instead of a delay.
What order should the work happen in? Not a list of problems. An order, with what each one costs to fix, so the slowest thing starts first rather than last.
How will we know if it worked? A number agreed before launch, so "is it working" has an answer that is not a demo.
There is one more finding worth sitting with. MIT also found that organisations working with outside partners reached deployment around 67% of the time, against 33% for teams building alone. That gap is not about talent — the internal teams are often stronger engineers. It is that an outside read arrives with nothing to defend: no budget it already argued for, no design it already picked, no meeting it already won.
The cheapest answer is the early one
Every number above describes money spent before anyone asked whether the foundations were there. Consultation is not the thing you buy instead of building. It is the short step that tells you whether the build is worth funding yet — and if the honest answer is not yet, that is the least expensive thing you will ever find out.