Every business is being told it needs AI right now. The pressure comes from every direction—competitors issuing press releases, vendors with impressive demos, board members who read an article on a flight. What almost nobody offers is the more useful question: does your business actually need AI, and if so, where?
Having built operational software, automation, and data systems for years—and now watching the same patterns repeat with AI that we saw with the cloud and “digital transformation” waves before it—we’ve developed a framework for answering that honestly. The uncomfortable truth is that for many businesses the best first answer is “not yet,” and recognizing that early saves an enormous amount of money and disillusionment.
Start with a problem, not the technology
The single biggest predictor of whether an AI project succeeds is whether it started from a specific, measurable business problem or from the desire to “do AI.”
Projects that start from the technology tend to play out the same way. Someone sees a demo. Budget gets allocated. A team goes looking for a place to apply the shiny new capability. The use case is chosen because it’s technically interesting, not because it’s valuable. Six months later there’s a prototype that works in a notebook, impresses in a meeting, and never touches a real customer or workflow.
Projects that start from a problem look different. “Our support team spends nine hours a day answering the same forty questions from our documentation.” “Underwriters manually read every submission and 80% follow an identical pattern.” “We lose deals because quotes take three days to produce.” These have a cost attached. They have a metric. They tell you immediately whether AI helped.
Before anything else, write down the problem in one sentence, with a number attached. If you can’t, that’s your first signal.
What makes a good first AI use case
Not every problem is a good fit for AI, and not every AI-suitable problem is a good first one. The strongest early use cases share a few traits:
The work is high-volume and pattern-heavy. AI earns its keep on tasks you do hundreds or thousands of times in roughly the same way. A task you do twice a month is rarely worth the engineering.
There’s tolerance for imperfection, or a cheap way to catch errors. AI is probabilistic. The best first use cases either tolerate the occasional wrong answer or keep a human in the loop to catch it. Drafting a response a person reviews is a great fit. Irreversibly approving a loan with no oversight is not—at least not on day one.
You can measure success. If you can’t tell the difference between a working solution and a convincing demo, you will ship the demo. A clear metric with a known baseline is what separates a pilot from theater.
The data already exists in usable form. The most common hidden cost in AI projects is data that turns out to be scattered, inconsistent, or locked in systems nobody can easily query. If the data the use case needs isn’t reasonably accessible, that’s the real project—not the AI.
The readiness gaps that quietly sink projects
When AI projects fail, it’s rarely because the model couldn’t do the task. It’s because the business around the model wasn’t ready. The gaps are unglamorous and very common.
Fuzzy use cases. “We want to use AI to improve customer experience” is not a use case; it’s an aspiration. Vague goals can’t be measured, can’t be scoped, and can’t fail or succeed cleanly—so they drift.
Messy data. Models are only as good as what they read. If your documents are inconsistent, your records are duplicated, or your knowledge lives in people’s heads, the AI inherits all of that. Cleaning and structuring data is often 70% of the real work, and it’s work that pays off whether or not you ever ship AI.
Undefined processes. AI struggles to automate a process that humans can’t actually describe. If the way work gets done is tribal knowledge that varies by who’s doing it, there’s nothing consistent for a system to learn or follow.
No owner. An AI feature is not “done” at launch. Model quality drifts, costs creep, usage patterns change, and providers update their models underneath you. If no one owns the feature after launch, it slowly degrades until someone notices it’s gotten worse.
The wrong driver. When the real motivation is “we need an AI story” rather than a problem worth solving, the project tends to optimize for announceability over usefulness—and quietly dies once the announcement is made.
The build-vs-buy question
Once you have a real use case, the next honest question is whether to build anything at all. Sometimes the best AI strategy is buying a tool that already solves your problem. If a mature SaaS product does exactly what you need, integrating it is almost always cheaper and faster than building.
Building makes sense when the use case is core to how you operate, depends on your proprietary data, or needs to live inside software you already own. In those cases, off-the-shelf tools either don’t fit or would require handing over data and control you’d rather keep. We dig into this trade-off in detail in our piece on build vs buy for AI, but the headline is simple: don’t build what you can buy, and don’t buy what’s core to your business.
A simple decision sequence
If you want a practical order of operations, here it is:
- Name the problem. One sentence, with a number. If you can’t, stop here and find one.
- Check the data. Does the use case’s data exist, and is it usable? If not, that’s your first project.
- Define success. What metric, at what baseline, would prove this worked?
- Decide build vs buy. Is this core and data-dependent, or does a tool already exist?
- Pilot small. Build the smallest production-shaped version, with evaluation from day one.
- Assign an owner. Decide who maintains it before you ship it.
Most businesses that work through this list discover one of two things. Either they have a clear, valuable, ready use case—in which case they should move quickly and deliberately—or they have foundational gaps to close first, in which case the right move is to fix those rather than force an AI project on top of them.
The honest answer is often “not yet”
There’s no shame in “not yet.” It’s the most common honest answer, and it’s far cheaper to hear now than after a failed six-month project. AI is a tool, not a destination. The businesses that get the most from it are the ones that reach for it deliberately, applied to a real problem they can measure—not the ones that adopt it because everyone else is talking about it.
If you want a quick gut-check on where you stand, our free AI Readiness Assessment walks through these same factors in nine questions and gives you a straight verdict—including what to fix first if the answer is “not yet.” And if you’d rather talk it through with engineers who’ll tell you the truth, that’s what we do.