What I Learned About AI from Consulting
Before I joined Anam, I spent a few months running Codify full-time, an AI development and consultancy practice. I helped startups and established businesses figure out how to use AI, which sometimes meant building something new and sometimes just meant working out what was possible.
I worked with a handful of companies across that period. Some engagements went well. Some didn't. The patterns that emerged were more consistent than I expected.
The pattern
Almost every company I worked with followed a similar arc. They'd arrive with a specific idea (usually inspired by something they'd seen ChatGPT do) and want to build it. The first conversation was about technology. The second was about data. The third, if we got that far, was about whether the thing they wanted to build was actually the right thing to build.
That third conversation was where the real work happened.
Most of them changed scope significantly after discovery. Some pivoted to a completely different problem, and a couple concluded AI wasn't the right solution at all. None of that was failure; it's what discovery is for. The worst outcomes were companies that skipped it and went straight to building.
Mistake one: starting with the model
The most common mistake I saw was companies choosing a model before defining the problem. "We want to use GPT-4" is not a product strategy. What user problem are you solving? What does success look like? What happens when the model gets it wrong?
This happened constantly. A founder would come in having already committed to a specific model, a specific architecture, sometimes even a specific prompt. The technology decision was made before the product thinking had started.
The result was predictable. They'd build something that worked for the demo scenario but fell apart when real users with real problems showed up. The model was rarely the issue; nobody had understood the problem properly.
The fix is straightforward but requires discipline: start with the user, work backward to the technology. What does the user need? What's the simplest way to deliver it? Does that require AI at all? If so, what kind? Only then do you choose a model.
Mistake two: ignoring the edges
Every AI system has a failure mode. Language models hallucinate, vision models misclassify, speech models mishear. The question is what happens when your system fails, not whether it will.
If you can't describe what your product does when the AI gives a wrong answer, you have a demo, not a product.
I saw companies pour months of effort into optimising the happy path while completely ignoring error handling: no fallbacks, no confidence thresholds, no way to hand off to a human. The implicit assumption was that the model would always be right, which is roughly equivalent to assuming your web server will never return a 500.
The companies that built resilient products spent almost as much time on failure modes as on the core functionality. Graceful degradation. Clear communication when confidence was low. Easy escalation to a human. None of this is glamorous, but it's the difference between a product users trust and one they abandon.
Mistake three: building infrastructure before validating demand
Before you build a custom model, fine-tune an existing one, or set up a GPU cluster, validate the core assumption with the simplest possible prototype. I've seen companies spend six figures on infrastructure for products that nobody wanted.
There's a particular flavour of this in AI worth calling out. Because AI products often require real infrastructure (fine-tuning pipelines, vector databases, GPU compute, evaluation frameworks) teams can spend months on foundational work before they have anything a user can touch.
The best engagements I ran started with a prototype built on top of an API. No custom models. No fine-tuning. Just a hosted LLM with a well-crafted prompt, wrapped in a simple interface. If users responded well to the concept, we invested in custom infrastructure. If they didn't, we'd spent days instead of months discovering that.
Mistake four: treating AI as a feature rather than a product
Some companies wanted to "add AI" to an existing product the way you'd add a search bar or a notification system. Bolt it on, tick the box, move on.
AI doesn't work that way. It changes the interaction model. It introduces non-determinism. It requires new forms of testing, monitoring, and user feedback. Treating it as a feature means it gets feature-level attention, a sprint or two of engineering time, when it actually requires product-level rethinking.
What worked
Not everything was mistakes. The engagements that went well shared some common traits.
Executive clarity on the problem. The best clients could articulate the business problem in one sentence before mentioning technology. "Our support team spends 60% of their time on questions that have documented answers." Clear, measurable, obviously worth solving.
Willingness to start small. The companies that shipped successfully started with a single use case and a single workflow. They resisted the temptation to build a "platform" before they'd proven a single feature.
Pick the single highest-value, lowest-risk use case and ship it. Learn from real usage. Then expand. This advice is so standard it's almost boring, but I watched company after company ignore it and pay the price.
Investment in evaluation. The best teams built evaluation frameworks early: not just accuracy metrics, but user satisfaction, latency tracking, and cost monitoring. They treated the AI component as something that needed ongoing measurement, not a one-time implementation.
Cross-functional teams. The projects that struggled were the ones where "the AI team" built something and then threw it over the wall to "the product team." The ones that worked had engineers, product people, and domain experts working together from day one.
What I carry forward
Even a few months of consulting taught me things I couldn't have learned any other way. I saw the same mistakes made by very different companies, which told me the mistakes were structural, not individual. And I saw what worked across contexts, which gave me confidence the patterns were real.
Seeing different companies tackle different problems keeps me honest about the gap between what AI can do in theory and what it actually does in practice.