Data is the moat nobody in legal tech wants to talk about

Ask a legal tech founder what makes their company defensible and you will hear about the team, the workflow, the user experience, the depth of their understanding of legal practice. All true, often. What you’ll rarely hear, at least not in public, is the word data. That’s odd, because in private almost everyone in this industry knows that once the models are roughly equal - and they increasingly are - the durable advantage comes from what your product learns that nobody else’s does. The silence isn’t ignorance. It’s discomfort, and I think the discomfort is worth examining, because it’s hiding the most important design decisions in legal software.

Why nobody wants to say it

The reason is simple. In legal tech, the data isn’t yours. It belongs to the firm’s clients, it is held under a duty of confidentiality, and the firm itself is nervous about where it goes. So a vendor who stands up and says “our moat is the data our customers give us” sounds, to a law firm, like a vendor announcing that it plans to monetise privileged material. Nobody wants that sentence attributed to them in a procurement meeting.

So the industry talks around it. Moats are described as “workflow”, “domain expertise”, “our proprietary approach”. Some of that is real. But it means the actual question - what does this product learn from use, and under what permissions? - goes unasked by buyers and unanswered by vendors, and gets settled by default in contract terms nobody reads closely.

It’s not the documents, it’s the decisions

The common assumption is that the moat is a big pile of legal documents. It mostly isn’t. Documents are abundant, a great deal of legal language is public or close to it, and a model that has read another hundred thousand leases is not meaningfully better at reading leases. The pile is not the prize.

What’s scarce is judgement captured in structured form. When a lawyer reviews an AI-generated report and changes a risk rating from low to high, that edit is enormously valuable. When they reject a suggested clause and choose a different one, when they consistently override the tool on a particular issue, when an answer is accepted unchanged a thousand times - those are labelled decisions by qualified professionals, made on real work with real stakes. Nobody can scrape that. It only exists inside a product that people actually use.

Which is the uncomfortable punchline for much of the industry: the data moat isn’t something you buy or license. It accrues to products that win adoption, and only to them. A tool nobody opens generates no signal at all.

Firms are sitting on a moat they can’t use

Firms like to believe their archive is their great untapped asset. Decades of precedents, matters and advice - surely that’s a moat? In theory, yes. In practice, most of it sits in a document management system that was organised for retrieval by a person who already knew what they were looking for. Matters are inconsistently tagged. Final versions are indistinguishable from drafts. The reasoning behind a decision lives in an email, or in a partner’s head, or nowhere.

And even where the documents are clean, the permissions aren’t. Information held for one client can’t simply be repurposed to benefit another, and firms are right to be careful about that. So the archive is less a moat than a very large, very expensive filing cabinet. The firms that will get value from their own history are the ones that start capturing structured information now, at the point of work, rather than hoping to excavate it later.

The permission problem is the design problem

Here’s where I think the honest conversation leads. If the moat is learned judgement, and the judgement is exercised on confidential client material, then the most important part of your product isn’t the model or the interface. It’s the data rights architecture - what is captured, what is retained, what is aggregated, and what never leaves the matter it came from.

There’s a real difference between learning that “reviewers at this firm always escalate this type of clause” and retaining the clause itself. There’s a real difference between improving one firm’s private configuration and pooling insight across every customer. Those distinctions are buildable, but only if you design for them from the first release. Retrofitting permissions onto a product that hoovered up everything is how vendors end up in exactly the conversation they were trying to avoid, usually at the worst moment, with their biggest customer.

What I’d build for

If I’m building legal software today, I instrument the workflow from day one, because every accepted answer and every correction is the product teaching itself what good looks like. I keep the learning as close to the firm as possible by default, and treat anything that crosses between customers as something that has to be earned, explained and agreed. I make the data terms short, explicit and boring, and I put them in front of the firm early rather than letting them discover the terms later.

And I’d rather be the vendor who says plainly “here is what we learn, here is what we keep, and here is what we never touch” than the one who hopes nobody asks. In a market this sceptical, the plain answer is a selling point. Buyers have learned to distrust anyone who is vague about data, and they are right to.

Data is the moat in legal tech, and pretending otherwise doesn’t make it less true - it just makes the terms worse for everyone. The companies that last will be the ones that are honest about what their products learn, careful about whose judgement they’re learning from, and good enough that people use them every day. The moat was never the pile of documents. It’s the trust that lets you keep learning.