Most software doesn’t fail because it’s poorly built. It fails because it doesn’t fit how people actually work — so it quietly gets worked around, and then abandoned. AI projects are especially prone to this, because the excitement around the technology makes it easy to skip the unglamorous parts that decide adoption.

Here’s the pattern I see, and what I do differently.

The failure pattern

It usually goes like this. Leadership buys a vision. A tool is built or bought to match an org chart — a tidy diagram of how work should flow. It’s demoed, everyone nods, and it ships. Then the people who actually do the job open it, find it doesn’t match the messy reality of their day, and go back to their spreadsheet. Six months later it’s “that system nobody uses.”

The technology was never the problem. The gap between how the work was imagined and how it’s actually done was the problem.

Start with the people who do the work

I run discovery with the people closest to the process — not just leadership. They know the exceptions, the workarounds, and the five-minute task that secretly takes an hour. That reality is what the system has to fit.

When you design around how a team already operates, the tool speeds them up instead of fighting them. Adoption stops being a training problem and becomes the natural path of least resistance.

Design for the exceptions, not just the demo

A happy-path demo is easy. Real work is full of edge cases, and an AI system that can’t handle them — or worse, handles them confidently and wrongly — erodes trust fast. Once people catch a tool being wrong, they stop relying on it.

That’s why I put guardrails in code, decide up front where a human must stay in the loop, and make the system’s limits explicit. A tool that admits “I’ll route this to a person” is trusted far more than one that bluffs.

Ship to production, then stay

A pilot that lives in a notebook proves nothing. I develop, test, and deploy real software that’s in production and in use. But launch isn’t the finish line — it’s the start of adoption.

I train the team, watch how they actually use it, gather feedback from daily users, and refine. The systems I’m proudest of aren’t the most technically clever; they’re the ones a team still relies on a year later because it genuinely made their job easier.

The short version

If you want an AI project that survives:

• Talk to the people doing the work before you design anything.
• Pick a real, repetitive pain — not the flashiest use case.
• Build for the edges and be explicit about limits so the tool earns trust.
• Ship it for real, then stay through adoption and iteration.

Do that, and “AI” stops being a buzzword and becomes something your team would complain about losing.

Wondering whether your next idea is set up to succeed? Take the AI readiness checklist or book a free discovery call — I’ll give you an honest read.