For the last ten years, running a law firm has been an integration project.
Think about where the operational energy actually went. You picked a practice management system. Then a document management system, and you spent a week finding out whether it really synced with the practice management system or just said it did. Then billing, e-signature, intake forms, calendaring, a PDF tool, legal research, phones, accounting. Then a fourth product whose whole reason for existing was to pass data between three of the others.
That was the game. From roughly 2015 to 2025, firm management meant assembling a stack of rented software that mostly got along, and eating the friction wherever it didn’t. Some firms got very good at it. The ones that won on operations were mostly the ones with the least-broken stack and a staff trained to live in its seams.
That era’s ending, and I don’t think most of the profession has noticed.
What actually changed
Custom software stopped being expensive.
It didn’t get cheaper. It fell off a cliff. The cost of getting a working, single-purpose tool that does exactly what your firm needs has dropped by something like two orders of magnitude in about two years. A capable model plus a person who knows what they want can now turn out, in an afternoon, the kind of internal tool that used to be a six-figure development engagement. Which means it never got built, because no three-lawyer firm has six figures lying around for internal tooling.
That’s the whole shift, and it flips the logic that created the SaaS market to begin with. Software-as-a-service existed because building your own was out of reach for anybody smaller than an enterprise. So you rented a vendor’s best guess at your workflow and bent your practice to fit it. Take away the cost barrier and that deal stops making sense. Why twist your screening process around a vendor’s form builder when you can have a form that matches how you actually size up a case?
So we’re heading into an era of bespoke software. SaaS isn’t dead. You’ll still rent the things that are genuinely hard and genuinely regulated: your accounting ledger, your filing interface, your email. But the connective tissue, the reporting, the workflows, the daily rhythm of the firm are yours to build now. The firms that build them will pull away from the ones that don’t, the same way the stack-assemblers pulled away from the paper firms.
The part nobody tells you
Here’s where it goes wrong, and it goes wrong the same way nearly every time.
You describe what you want in plain English. The model builds it. It looks amazing. Then you try to make it do a second thing, and a third, and somewhere around week three the whole thing caves in. Nothing dramatic. It just turns into a pile of features that contradict each other, with the same client address stored in four places and no way to answer a question you didn’t think of on day one.
People call this vibe coding, and it’s real, and it works. The demo isn’t a trick. But the vibes carry you to a wall. What gets you over the wall isn’t talent, and it sure isn’t learning to code. The model writes better code than I ever did.
What gets you over is a small vocabulary — five or so structural ideas that let you say what you actually want, spot it when what came back is wrong, and know what to ask for next.
I picked those ideas up before law school, working in business systems, back when enterprise software meant relational databases, batch jobs, and a lot of people who understood data models arguing with a lot of people who didn’t. For fifteen years that background was a cocktail-party fact. Not anymore. So here they are, in the order they matter.
One: every fact lives in one place
This is the big one, and it’s the one lawyers get wrong most reliably.
The idea came out of IBM research in 1970 and nobody’s meaningfully improved on it since: every fact lives in exactly one place, and everything else points at it.
Your practice has entities. Clients. Matters. Documents. Deadlines. Hearings. Time entries. Opposing counsel. Judges. Courts. Each one is a thing with attributes, and things relate to other things. A matter belongs to a client. A time entry belongs to a matter. A hearing belongs to a matter, a judge, and a courthouse.
The rule is simple. Store the client’s address once, on the client record. Not again on the matter. Not a third time in the intake spreadsheet and a fourth in the letterhead template. Store it once. Everywhere else, point to it.
Here’s why that’s a practice problem and not a tech problem: nearly every operational screwup in a small firm breaks this rule. A client moves and three of your five systems keep the old address. A service date shows up one way in the calendar and another way in the file, and the deadline computed off it is wrong. Billing shows work on a matter that intake shows as closed. Same bug every time. One fact stored twice, and the copies drifted apart.
When you build your own tools, you get to fix that at the root. You decide what the entities are and which one owns each fact. That decision — the schema — is the most valuable hour you’ll spend, and it’s an hour of legal judgment, not engineering judgment. Nobody can do it for you, because nobody else knows that in your practice a matter sometimes has two clients, that a deadline is a different animal from an appointment, or that “closed” means three different things depending on who’s asking.
So before you build anything, write down the nouns of your practice and draw the lines between them. That’s a data model. Get it right and it’ll carry almost anything you stack on top of it. Get it wrong and it won’t carry anything for long.
Two: the data isn’t the report
This one will change how you think about your firm’s information.
The data is one thing. The way you look at it is a completely separate thing.
In database terms that’s a view. One set of facts, shown a hundred different ways, never copied. The morning report, the client status letter, the year-end profitability numbers, the deadline calendar, the list of everything served last week — that’s not five piles of information. It’s one pile seen from five angles.
Lawyers don’t think this way, and there’s a good reason we don’t. What we make for a living is documents. A brief is a fixed object. A file is a folder of fixed objects. We’re trained to treat the document as the unit of truth, so when we want a new kind of report, our instinct is to make a new document, by hand, and keep it up forever.
That instinct costs this profession a staggering amount of time. Every status report you’ve ever pieced together by hand from four other places was a view you computed yourself, using your own attention as the search engine, at your hourly rate.
Once that sinks in, your questions change. You quit asking where’s the spreadsheet that tracks X and start asking what would I have to record so X can just be computed? You stop building reports and start building the record that makes any report nearly free.
Here’s how it works for me. I don’t keep a list of urgent matters. I keep matters, deadlines, and hearings, each recorded once, and “urgent” is a question I ask of that data. It gets regenerated every morning, and it’s never stale, because there’s nothing to update. Move a deadline and the view moves with it. There’s no second copy to forget about.
That one shift — from documents I maintain to data I record and views I generate — is worth more to a small firm than any software purchase of the last decade. It’s also what makes a firm wiki your AI can actually query work, instead of turning into one more folder nobody opens.
Three: APIs, and MCP
The third idea is connection.
An API — application programming interface — is the door a piece of software leaves open for other software. If your practice management system has one, there’s a set way for an outside program to ask it questions (what matters are open?) and tell it things (create this time entry). Every “integration” you’ve ever bought is one product talking to another product’s API.
For two decades, using an API took a developer. That’s why you bought integrations instead of building them, and why your integrations only ever did what some product manager thought of.
Now the model can use the API directly. What your systems can do together isn’t limited by a vendor’s roadmap anymore. It’s limited by what you can describe.
MCP — the Model Context Protocol — is the newer piece, and it’s the one to understand, because it changes what kind of thing an AI is, not just how good it is. MCP is an open standard for handing a model a set of tools and telling it, basically, here’s what you can do in the world. Not text to read. Actual capability. Read that calendar. Search that inbox. Create that task. Pull that ledger.
That’s the entire gap between an AI that can talk about your practice and one that can act on it. One’s a very well-read assistant locked in a room. The other has keys to the office.
The payoff is a buying rule. Stop asking does this vendor integrate with that vendor. Ask does this system expose an API. If it does, you can wire it to anything, any way you want, without waiting on anybody. If it doesn’t — if a vendor locks your data behind a screen with no programmatic door — that’s a serious strike now, and it should count for a lot. Being able to reach your data is starting to matter more than whether the tool is any good. I’ve written separately about what it took to connect a model to a practice management system whose vendor hadn’t implemented the standard. The code was the easy part.
Four: build the screen last
There’s a design rule called separation of concerns. The version that matters here: storage, logic, and presentation are three different layers, and you build them in that order.
Storage is where the facts live. Logic is the rules that run on them — how a deadline is computed, what makes a matter urgent, when a bill’s ready to go. Presentation is what a person sees: the screen, the page, the report.
People who aren’t technical almost always start with presentation, because it’s the only layer they’ve ever seen. They describe the dashboard. And models are dangerously good at cranking out a beautiful dashboard, which is exactly why the first version looks amazing and the second one falls apart. There was nothing under it.
Build in the right order and the screen is close to disposable. Solid data model, rules spelled out, and the screen is a thin skin you can regenerate in twenty minutes. Want it as a web page today, a printed PDF tomorrow, a message in a chat channel on Friday? Same data, same logic, three skins, and nothing that mattered ever lived in the skin.
That’s the SaaS deal turned upside down. With SaaS, the screen was the product, and your data was a hostage inside it.
Five: the less famous ones
A few more, lower profile, that separate systems that last from demos.
Deterministic versus probabilistic. Software is deterministic: same input, same output, every time. Models are probabilistic: a very good answer, usually. Know which one you’re leaning on, and for what. Deadline computation, conflict checking, and trust accounting have to be deterministic code, because usually right isn’t a standard the rules recognize; Rule 1.15 requires books and records maintained on a current basis, not a good-faith estimate. Summarizing a document, drafting a first pass, sorting inbound mail — probabilistic is fine there, because a human reviews the output before it matters. Deciding which side of that line a task falls on is a call about consequences, and that’s a call lawyers are actually trained to make. It’s the same call that separates verifying form from verifying truth.
Source of truth. For every fact, one system is the boss and everything else is a copy. Write that down, because when two systems disagree — and they will — you need to have already decided which one wins. Most firms have never made that call on purpose, so they settle every conflict by arguing about it, at the worst possible moment.
Events versus state. State is what’s true right now. Events are the record of what happened. Most systems only store state, which is why you can never figure out why something changed. Keep an append-only log of events and you get an audit trail, an explanation, and answers to questions you didn’t know you’d have. In a profession where the record is the whole ballgame, this should come naturally. Mostly it doesn’t.
Idempotency. An operation you can run twice without doing any damage. It sounds like a technical footnote. It’s the difference between automation you can trust and a system that bills a client twice because a job ran on Tuesday and again on Wednesday. Along with failures that say nothing, it’s where the quiet damage actually comes from.
What to do Monday morning
You’re not going to become a software engineer, and you shouldn’t try. None of this is about making you technical. It’s about making you articulate — giving you the small vocabulary you need to boss around a machine that does the technical part.
Start here. Write down the nouns of your practice and how they connect. Decide, for every important fact, which system owns it. Quit maintaining any list that could be computed from data you already have. Ask every vendor whether your data is reachable programmatically, and treat no as close to a dealbreaker. And when you sit down to build, describe the data before you describe the screen.
There’s a professional angle here too. Comment 8 to Rule 1.1 says competence includes keeping abreast of the benefits and risks of relevant technology. For a decade people have quoted that as a nudge to go buy e-discovery software. It reads differently when the technology is the ability to build the thing your practice needs.
The last decade rewarded lawyers who were good at choosing software. The next one will reward lawyers who are good at describing it. Look at that straight on and it’s a drafting skill. We’ve been training for it our whole careers.
The tools were never the moat. A clear, correct picture of how your practice actually works is the moat. Software was only ever the way to write that picture down, and it used to cost too much to bother.
It doesn’t anymore. So the cost of serving a client competently is about to drop for anybody willing to do the thinking, and that’s the only reason any of this is worth publishing.
Sources
- E. F. Codd, A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, Vol. 13, No. 6 (June 1970), pp. 377–387
- Model Context Protocol — open standard for connecting AI applications to external tools and data
- Minn. R. Prof. Conduct 1.1 and cmt. [8] (competence includes keeping abreast of “the benefits and risks associated with relevant technology”)
- Minn. R. Prof. Conduct 1.15 (safekeeping property; books and records maintained on a current basis)
General commentary on practice management. Not legal advice, not ethics advice, and not a recommendation of any particular product or vendor. No client information appears in this article; all examples are generic.