The real first question isn’t “should we use AI?” It’s “which kind of AI, if any, actually fits this problem?” Answering that honestly is what an AI feasibility assessment is for, and it’s worth doing before a single line of model code gets written.

## The question behind the question

“AI” isn’t one decision. In practice it’s usually a choice between three very different paths:

– Using an existing API (OpenAI, Anthropic, Google, etc.) as-is
– Fine-tuning an existing model on your own data
– Training something custom from scratch

Each has a wildly different cost, timeline, and maintenance burden. Skipping straight to “let’s build a custom model” without ruling out the first two is where most of the wasted spend happens.

## A four-part feasibility framework

This is close to the actual checklist we run through with clients before scoping any AI engagement.

### 1. Is the problem actually well-defined?

AI is good at problems with a clear input, a clear output, and enough historical examples to learn the pattern between them. “Help customers faster” isn’t a well-defined problem. “Classify inbound support tickets into these 12 categories” is. If you can’t describe the input and the desired output in one sentence each, the project isn’t ready for a feasibility assessment yet — it needs a scoping conversation first.

### 2. Is there enough of the right data?

Not just data volume — data that actually reflects the task, labeled or labelable, and reasonably clean. A support inbox with 200,000 emails sounds like plenty, until you find out only 400 of them are tagged with an outcome you can train against. This step alone kills or reshapes a large share of “AI ideas” before any real cost is incurred.

### 3. What does it cost to be wrong?

This is the step people skip most often. A recommendation engine that’s wrong 15% of the time is a minor annoyance. A model that’s wrong 15% of the time when it’s flagging financial transactions or medical intake forms is a liability. The acceptable error rate should shape the entire approach — including whether a human needs to stay in the loop, and whether “good enough” AI is even appropriate here at all.

### 4. Build, fine-tune, or buy?

Once the first three are answered honestly, this becomes a much easier call:

– **Buy (use an existing API as-is)** when the task is general enough that a foundation model already handles it well, and your data doesn’t contain anything proprietary or sensitive that changes the answer.
– **Fine-tune** when the general model is close but consistently misses your domain’s specifics — tone, terminology, edge cases specific to your business.
– **Build custom** only when the problem is specific enough, the data is large and clean enough, and the cost of using a general model would be genuinely worse — not just “less impressive.”

Most business problems we see land in the first two categories. Full custom builds are rarer than the AI hype cycle suggests, and that’s not a limitation — it’s usually the more defensible engineering decision.

## Where MLOps fits in

Feasibility doesn’t stop at “can we build it.” A model that works in a notebook and a model that survives production are different problems. Before greenlighting any approach, it’s worth asking who owns retraining when the data drifts, how you’ll monitor for degraded accuracy in the wild, and what happens when the underlying API you depend on changes its behavior with an update you didn’t ask for. This is the same reasoning that shapes our Data & MLOps work — the infrastructure question isn’t separate from the feasibility question, it’s part of it.

## The takeaway

If you’re evaluating an AI idea right now, don’t start with “which model should we use.” Start with the four questions above, in order. Most of the time, you’ll find the honest answer is a smaller, cheaper, faster path than the one you walked in wanting — and that’s a good outcome, not a disappointing one. The goal was never to use AI. It was to solve the problem.

If you’re not sure which category your project falls into, that’s exactly what an AI feasibility assessment is for — get in touch and we’ll walk through it together before you commit budget to a direction.