What I Look for Before Taking an AI Consulting Project

I've said no to more projects than I've taken. That's not a flex. It's just the reality of doing this work for a few years and learning what actually succeeds versus what looks like it will succeed.

Bad AI projects don't fail because of bad code. They fail because the setup was wrong before the first line was written. So here's what I check in the first conversation.

Is there a real problem — or just AI curiosity?

The single biggest predictor of a project going nowhere is when the client says something like "we want to explore AI" or "we need an AI strategy."

That's not a problem. That's a mood.

I need to hear something specific. "We have 3 people spending 6 hours a day manually processing these documents and it's killing our growth." That's a problem. "We want to be an AI-first company" is not.

This isn't me being difficult. It's that AI is just a tool. Tools solve specific problems. If you don't have a specific problem, there's nothing for the tool to do — and you'll end up with a demo that nobody uses.

Does someone internal own the outcome?

Every project I've seen fail without a clear technical problem had one other thing in common: nobody inside the company was personally responsible for it working.

A good sign: a CTO who will personally test the system, or a founder who is directly affected by the problem we're solving. They have skin in the game. They'll tell me when something is wrong. They'll push to get the system actually used.

A bad sign: "our team wants to experiment with AI" or "we have budget approved for an AI initiative." When it's nobody's problem specifically, it becomes nobody's priority when things get hard. And things always get hard at some point in a build.

Does the data exist?

This one catches a lot of people off guard.

Most AI systems need data. RAG needs documents. A classifier needs examples. A pipeline that processes customer emails needs access to those emails. Sounds obvious, but I've been in early conversations where the client assumed I could build something before the data existed or before they had access to it.

I ask early: "Can you show me what the data looks like right now?" If they can't answer that in 10 minutes, we're not ready to build yet.

Data access issues — permissions, format, privacy, inconsistency — are the most common reason timelines blow up. I'd rather know about them in week 1 than week 6.

Is the scope specific enough to finish?

I've learned to be suspicious of projects that sound big and impressive. "AI-powered ops platform" or "end-to-end AI transformation" are red flags, not because ambition is bad but because vague scope means the project never actually ends.

The scopes I like best: "automate this one specific workflow" or "replace this one manual step." We can define done. We can test whether we're done. We can ship it and move to the next thing.

I'm happy to work on something that expands over time. But the first engagement needs to have a clear finish line. If we can't agree on what "complete" looks like before we start, we won't agree on it when we get there either.

Do they want something built or just validated?

Sometimes a client doesn't actually want a production system. They want to know if AI can solve their problem. That's a legitimate thing to want — but it's a different engagement than building something that runs in production.

I've done both. Validation projects are shorter, cheaper, and end with a recommendation and a prototype. Production builds are longer, involve real data, real integrations, and end with something the team actually uses.

The mistake is when a client says "build it" but means "show us if it's possible." Then you build something real, they treat it as a prototype, and the handoff never happens. Very frustrating for everyone.

I now ask directly in the first call: "When this is done, what does your team do differently?" If they don't have a clear answer, we're probably talking about a validation, not a build.

What happens when these aren't in place

I've worked on projects where I ignored some of these signals because the problem seemed interesting or the client seemed smart. It never ended well. Either the project dragged on without a clear end, or we built something great that nobody used, or the scope kept shifting until the original system didn't fit anymore.

The best projects I've worked on had all five. Specific problem. One person who owned it. Data ready. Clear scope. Agreed definition of done. The code was the easy part.

If you're thinking about a project and aren't sure if your situation checks these boxes, that's worth a 30-minute call to figure out before anything else. I do that for free. It's better for both of us to know early.