There's a Word for That: Most Legal Software Is Built by People Who've Never Billed an Hour

A practicing lawyer and a software engineer or developer can look at the same screen and see two completely different things. Did you know there are specific terms for the disconnect between software creators and the people who use their software? They had to coin terms for it because it's such a widespread problem, I guess.

For example, most legal software is designed and built by engineers and developers who have never practiced law. The people writing the code are careful and good at their jobs. They read the requirements doc, watch the user interviews, and sit through the demos. But most of them have never had to reconstruct yesterday's time from memory at 11:00pm to make sure their billable hours are logged, or stop in the middle of a client call to hunt for a document that lives in a different platform than the matter management system.

The term for this is empathy gap: it's when software creators fail to truly understand the user's daily frustrations, pressures, and environment, resulting in a tool that feels robotic and impractical. There's a steep empathy gap between the people who build legal tools and the people who live inside them all day, which is why so much legal software is technically complete and practically unusable.

I've been an attorney for more than a decade. I was an owner/manager of a small firm with 5 employees, and then I was a senior attorney at a 50-lawyer firm (total headcount of 120+). Two very different worlds. But one thing was consistent across both worlds: about 50% of the software's features were actually used day-to-day, while the other 50% suffered from a severe workflow-user mismatch, meaning the engineered sequence of steps in the software did not align with the lawyer's natural, real-world habits.

Now that I'm building legal tech — and immersed in tech circles — I know exactly why most legal practice management platforms are not designed for how lawyers actually work. The answer: non-lawyer software engineers with no domain expertise are building these platforms, resulting in an operational disconnect between how software designers think a law firm runs versus the sometimes messy, fast-paced reality of how lawyers actually manage their day.

Here are three things I only understood once I was behind the scenes designing legal tech software:

1. Capturing time is a workflow problem

Ask a software designer for a "time entry feature," and you get a clean form to fill in: matter, date, duration, description, save. It validates, and it demos beautifully. It's also tedious and time-consuming data entry.

For lawyers, capturing must happen in the work — while we're in the document, on the call, drafting the email — or it becomes an end-of-day reconstruction exercise, which is exactly where revenue disappears. A lawyer-builder designs time entry and passive timekeeping features so you rarely have to touch them. A non-lawyer builder with no domain expertise writes the code for a time entry form and calls it a day, completely blind to this workflow-user mismatch and oblivious to whether lawyers want something different.

2. The matter is the unit of thought

Software databases want to organize around clean tables: contacts in one place, invoices in another, documents in their own spot. That is the natural way to model the data, and it is the wrong way to model the work for lawyers. A lawyer doesn't think in tables; we think in matters (cases). "Where are we on the Jones case?" is a single question, and answering it should not require opening four programs and assembling the picture in your head.

When software organizes legal data around technical database tables instead of "the matter," it creates massive cognitive friction: the lawyer has to work harder mentally just to manually piece together a case's timeline across multiple screens.

When the matter is the organizing principle — every document, time entry, communication, task, and note is recorded against it — the software finally matches the shape of the question being asked. I've made the architectural case for that before. The narrower point here is that you don't arrive at matter-centric design from a database diagram; you arrive at it because you've felt the operational disconnect of working without it.

3. Compliance is a daily anxiety, not a checkbox

For many software designers, "trust accounting" is just a checkbox on a feature list. To a practicing lawyer, the trust account is a low hum of risk running underneath every month, because the failure mode there is not a bug ticket — it's a bar complaint. Software built by people who have felt that hum treats the compliance record as something the system produces continuously, as a byproduct of the work. Software built from the fancy feature list treats it as a module to ship. The two look identical in a demo but feel nothing alike when a bank reports an overdraft on the trust account. Non-lawyer developers build a "feature factory" in which tracking compliance is reduced to a hollow checkbox in a demo sales pitch, completely missing the daily anxiety of a real attorney.

Why the empathy gap survives

None of this is a slight against software designers; it's a structural problem with the way most legal software is made. The people writing the code are not the ones whose licenses are on the line, so the features and requirements that reach them are filtered through a product manager, a sales call, and a feature request, meaning the vital texture of the workflow gets lost in translation. What survives the filter is the part that is easy to write down: the form, the table, the checkbox.

When non-lawyers build legal tech, they rely on explicit requirements. They conduct interviews, watch demos, and read feedback forms. But explicit requirements only capture what a lawyer can articulate in a brief feedback session. They completely miss the implicit realities — the unwritten, high-stakes psychology of practicing law.

True domain expertise isn't just about knowing legal terminology; it's about understanding the ambient anxiety of running a firm, the precise micro-moment your focus fractures during an unexpected client call, and the gut-wrenching dread of a potential compliance error. A non-lawyer product manager sees "conflict checks" and "calendaring deadlines" as a feature checkbox for a sales demo while an attorney sees it as a low hum of a bar complaint or malpractice risk that runs beneath their entire practice.

Building a tool for a job you actually do introduces a massive design advantage: it completely eliminates the translation filter.

As a practicing lawyer who designs and builds legal tech, my loop is instantaneous. When an administrative task during my week is clunkier than it should be, that friction doesn't get summarized, generalized, or deprioritized by a committee. It goes straight into the architecture. I am not guessing what the customer feels because I share the exact same deadlines, the same operational bottlenecks, and the same regulatory oversight.

Domain expertise allows us to stop building software that forces lawyers to adapt to technical database structures. Instead, it allows us to build technical systems that naturally conform to how a lawyer actually thinks.

The test worth running

This is the test I would give any firm evaluating legal software, Batesly included: look past the feature list and ask whether the tool behaves as if it were built by someone who has sat in your seat. You can usually tell within an hour, and the tells are small. Does time capture get out of your way or demand your attention? Does the matter hold everything or scatter it? Does the compliance record assemble itself, or do you have to assemble it under a deadline?

The feature list is the easy part — any well-funded team can ship the feature list. The hard part is whether the people who built it have ever felt the problem they're solving.