July 2026
The hardest part of legal tech isn’t the tech
Legal tech is full of hype. The numbers behind it are less glamorous. Depending on who you ask, somewhere between half and 80% of implementations fail. For a profession that prides itself on risk management and diligence, that’s cause for reflection.
In our June CPD webinar, David Curtin met with Gene Turner (MD of LawHawk) and Zubin Pratap (Head of Developer Relations at Cartesia) to discuss what actually goes wrong, and what to do about it. One thread ran through the whole conversation: when legal tech fails, the tech itself is rarely the culprit.
Here are some key points from the discussion.
The trouble starts before you buy
Most failures trace back to the very beginning, when nobody’s really agreed on the problem they’re solving, why it matters, or why now. The current process usually isn’t as well understood as people assume, either. One example from the session: a workflow everyone called “simple” ran to more than 100 steps once it was mapped and took weeks just to pin down.
Legal and tech still don’t speak the same language
The two worlds are further apart than many think, and they often use the same words to mean different things. Arbitrariness, for instance, is a flaw in law but a real strength in computing. Add the habit of treating AI as a magic fix for everything, and the gap between what people expect and what they get keeps widening.
Time is the budget everyone forgets
Money is what most teams budget for. But a tool only feels effortless once you’ve put in the hours to learn it, and that learning curve gets underestimated almost every time. A realistic sense of the effort involved.
Learning can’t be left to the keen few
Ask around, and you’ll find the people who’ve mastered a new tool usually did it in their own time. That’s a cultural problem. If adoption depends on the enthusiastic 10% putting in unpaid hours, it’ll always be patchy, and the tech ends up taking the blame. If a tool matters, the time to learn it must be carved out during work, with leadership behind it.
The best question for a vendor is how it could fail
Instead of asking what’s great about a product, ask what would make it fail you in twelve months. It’s a more honest conversation, and it brings the risks out into the open while you can still do something about them. If the answer’s vague or evasive, that tells you something, too.
What you’re really buying is a relationship
Technology moves quickly enough that what you need in six months won’t be what you need today. So, the people behind the product, and how they work with you as things change, matter more than the feature list on day one. Test that with a small piece of work before you commit. It cuts both ways, too: the clients who get the best results are usually the ones who are easy to deal with and quick to respond.
Don’t try to predict where the tech is heading
It’s hard to predict where thigs are going. Rather than betting on the future, look at how teams like yours are using a tool right now and reason from there. And it’s worth remembering that choosing not to adopt something is a legitimate decision.
The full webinar gets into all of this in more detail. You can watch it below.
