Every year, enterprise teams invest in AI projects that don’t ship. The model works in the demo. The vendor is credible. The business case stacks up. And then, somewhere between pilot and production, the whole thing quietly stops.
We’ve been building AI products for enterprise teams since 2016 and we’ve seen this pattern enough times to know: the model is almost never the problem. The gap is almost always in what happens around the model — the deployment plan, the integration reality, and the change management no one budgets for.
Three patterns we see most often
The integration is more complex than anyone admitted
Enterprise data doesn’t sit in one clean API. It lives across a CRM, a legacy ERP, a shared drive, and a handful of spreadsheets no one has migrated in years. Pilots usually test against a sample data set. Production meets reality. The team that sold the project is rarely the team that has to make the systems talk — and the people who do know how messy it is often don’t have a seat at the table until month four.
No one owns the answer quality
A generative AI system with no human in the loop is a liability waiting to happen. But if the review process is too heavy, the business case falls apart — why pay for AI if a human has to read every output? The teams that ship and stick are the ones who design the review gate before they start: which categories of outputs need human sign-off, which confidence thresholds trigger a review, and who is accountable when something is wrong.
The people who use it weren’t involved in building it
An AI product is only useful if the people it’s meant to help actually trust it. That trust doesn’t come from a launch email. It comes from those users being involved from the start — telling you what questions they actually ask, what a wrong answer costs them, and what they’d need to see before they’d rely on the output in front of a customer.
“The model was fine. What we underestimated was how much trust the team needed to build before they’d change the way they worked.”
What we do differently
Before we write a line of code, we run a four-part scoping process with the team that will actually use the product. We map every data source that needs to connect. We agree on a review gate structure. We identify the two or three workflows that will prove value in the first six weeks. And we build those first — not the most technically interesting parts, but the ones that will make a sceptical operations manager say “this actually works”.
The result is that our projects ship. Not because we have better models — there are plenty of capable models available. But because we treat deployment and adoption as the product, not an afterthought to it.
Recognise any of these patterns?
Walk us through what you’re building — we’ll tell you where the risk usually sits.
A practical checklist before you start
-
Map every data source that needs to connect — not just the ones in the original scope.
-
Agree on review gates before you build — what needs a human sign-off, and who.
-
Pick two workflows to prove value in the first six weeks — not the most interesting ones, the most sceptic-converting ones.
-
Involve the end users from week one — their trust is the product.
-
Define what “shipped” means — a live URL isn’t enough. What metric changes in 90 days?
None of this is new advice. Most of it gets deprioritised because the early stages feel like momentum — a working demo, enthusiastic stakeholders, a signed contract. The danger zone is exactly that moment. It’s when the unglamorous work of deployment either gets planned properly or gets deferred until it’s someone else’s problem.
