Most AI projects at small and mid-sized companies don't fail because the model wasn't smart enough. They fail because nobody pinned down what problem they were solving, the data was a mess, or no one owned the result after launch. The good news is that you can catch all of that before you spend a dollar on building.
This is the checklist we run before starting any AI build. Work through it honestly. If you can answer every item with something concrete, you're ready. If three or more items are vague, fix those first, that's cheaper than learning the same lessons mid-project.
1. A specific use case tied to a metric
"We want to use AI" is not a use case. "We want to cut the time our team spends triaging inbound support tickets" is.
The test is simple: can you name the task, who does it today, and the number that should move? If the number is fuzzy ("be more efficient"), the project will be impossible to judge later. Pick something you can measure, hours per week, response time, error rate, quote turnaround, leads followed up within an hour.
- Name the task in one sentence.
- Identify who owns that task now.
- State the one metric you expect to change.
If you can't tie it to a metric, you're not ready to build, you're ready to investigate.
2. Data you can actually reach
AI runs on your data, and for most SMBs the data is the bottleneck. Before anything else, find out where the relevant information lives and whether you can get to it.
Ask:
- Does the data exist at all, or would we have to start collecting it?
- Is it in a system we can export from or connect to through an API?
- How clean is it? Duplicate records, blank fields, and free-text fields holding ten different formats all add work.
- Is any of it sensitive (customer PII, health, financial), and does that change who can touch it?
You don't need perfect data. You need to know its real condition, because cleaning and connecting it is usually the largest part of the effort. Be skeptical of any plan that assumes the data is "basically fine."
3. Integration points
A useful AI feature has to plug into the tools your team already uses. An answer that sits in a separate dashboard nobody opens delivers nothing.
Map the path the work takes today and where AI would sit in it. If a draft email needs to land in your CRM, confirm the CRM has an API and that you're allowed to use it on your plan. Watch for systems with no integration story, manual copy-paste steps, and vendor lock-in that blocks exports.
The reusable patterns here are the same ones behind most custom software work, get the integration points right and the rest gets much easier.
4. Guardrails and risk
Decide what happens when the AI is wrong, because it will sometimes be wrong. Language models can produce confident, fluent answers that are simply incorrect, so the question is never "will it make mistakes" but "what do mistakes cost us, and how do we catch them."
- What's the worst plausible bad output, and who would see it?
- Does a human review the output before it reaches a customer, or does it go straight out?
- Where's the audit trail when you need to explain a decision?
- Are you putting confidential or regulated data into a third-party model, and is that allowed?
High-stakes uses (anything touching money, contracts, medical, or legal) need a human in the loop. Lower-stakes internal drafts can run with lighter checks. Match the guardrail to the risk, don't apply the same level to everything.
5. A named owner
Every AI system needs a person, not a committee, responsible for it after launch. Models drift, data sources change, and edge cases show up that nobody imagined. Without an owner, the tool quietly degrades until people stop trusting it.
Name who owns the day-to-day result, who they escalate to, and who handles the technical side when something breaks. If the honest answer is "we'll figure that out later," the project isn't ready to start.
6. Honest budget and timeline
AI projects have costs beyond the build: data cleanup, integration work, ongoing model/API usage fees, and the staff time to review and maintain output. A pilot that looks cheap can carry real monthly running costs once it's live.
Set a budget for building and a separate expectation for running it. Decide how much time your team can give to testing and feedback during the build, that participation matters more than most people expect. And give it enough runway to prove itself; a two-week deadline rarely survives contact with messy real-world data.
7. Clear success criteria
Before you build, write down what "this worked" looks like, in numbers, agreed on by the people who'll judge it.
- The metric from item 1, with a target ("triage time drops from 20 minutes to under 5").
- A baseline measured today, so you can compare honestly.
- A date to check against.
- An explicit threshold for "this isn't worth keeping."
That last one is the one teams skip, and it's the most valuable. Deciding in advance what failure looks like keeps a struggling project from limping along on sunk-cost momentum.
8. A plan to iterate
The first version will be good at some things and bad at others. That's normal. What separates projects that pay off from ones that stall is a plan to learn from real use and adjust.
Decide how you'll collect feedback, how often you'll review what the system gets wrong, and who triages those issues. Start with a narrow slice, one team, one workflow, prove it there, then expand. A small thing that works beats a broad rollout that nobody trusts.
The takeaway
Readiness isn't about having the fanciest tools. It's about knowing your problem, your data, your guardrails, and your owner before you build. Run this checklist and the weak spots show themselves, usually in items 2, 5, and 7.
If most of these are solid and a couple need work, you're in good shape to start. If you want a second set of eyes on where you stand, that's the kind of thing we walk through on a first call, no obligation to build anything.