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 spent a week finding out whether it really synced with the practice management system or only claimed to. Then billing, e-signature, intake forms, calendaring, a PDF tool, legal research, phones, accounting. Then a fourth product whose entire reason for existing was to pass data between three of the others.
That was the game. From roughly 2015 to 2025, firm management was the art of assembling a stack of rented software that mostly cooperated, and absorbing the friction wherever it didn’t. Some firms got very good at it, and the ones that won on operations were largely the ones with the least-broken stack and staff trained to live inside its seams.
That era is ending, and I don’t think most of the profession has noticed.
What actually changed
Custom software stopped being expensive.
Not cheaper — collapsed. The cost of getting a working, single-purpose tool that does exactly what your firm needs has fallen by something like two orders of magnitude in about two years. A capable model plus a person who knows what they want now produces, in an afternoon, the sort of internal tool that used to be a six-figure development engagement — and therefore never got built, because no three-lawyer firm has six figures for internal tooling.
That is the whole shift, and it inverts the logic that created the SaaS market in the first place. Software-as-a-service existed because building your own was out of reach for anyone smaller than an enterprise, so you rented a vendor’s approximation of your workflow and bent your practice to fit it. Remove the cost barrier and the bargain stops making sense. Why contort your screening process around a vendor’s form builder when you can have a form that matches how you actually evaluate a case?
So we are moving into an era of bespoke software. Not the end of SaaS — you will 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 operating rhythm of the firm is now yours to build. And the firms that build it 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 is where it goes wrong, and it is worth saying plainly because the failure is so consistent.
You describe what you want in plain English. The model builds it. It looks extraordinary. Then you try to make it do the second thing, and the third, and somewhere around week three it collapses — not dramatically, just 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 anticipate on day one.
People call this vibe coding, and it is real and it genuinely works. The demo is not a trick. But the vibes carry you to a wall, and what determines whether you get past the wall is not talent, and it is emphatically not learning to code. The model writes better code than I ever did.
What gets you past the wall is a small conceptual vocabulary — five or so structural ideas that let you say what you actually want, recognize when what came back is wrong, and know what to ask for next.
I learned those ideas 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. It is not a cocktail-party fact anymore. So here they are, in the order they matter.
One: the relational model
The most important idea, and the one lawyers most reliably get wrong.
The principle came out of IBM research in 1970 and has not been meaningfully improved on 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 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 discipline says: 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, refer to it.
Why this is a practice problem and not a technical one: nearly every operational failure in a small firm is a violation of this rule. A client moves and three of your five systems keep the old address. A service date appears one way in the calendar and another in the file, and the deadline computed off it is wrong. Billing shows work on a matter intake shows as closed. Same bug every time — one fact stored twice, and the copies drifted.
Building your own tools lets you fix that at the root. You decide what the entities are and which one owns each fact. That decision — the schema — is the highest-leverage hour you will spend, and it is 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 is asking.
Practical version: before you build anything, write down the nouns of your practice and the lines between them. That is a data model. A model can carry almost anything built on top of it; a bad one carries nothing for long.
Two: data and views are different things
The second idea, and the one that 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 is a view. One underlying set of facts, presented a hundred different ways, never duplicated. The morning report, the client status letter, the year-end profitability analysis, the deadline calendar, the list of everything served last week — that is not five bodies of information. It is one body of information seen from five angles.
Lawyers structurally do not think this way, and there is a good reason. Our professional artifacts are documents. A brief is a fixed object. A file is a folder of fixed objects. We are trained in a paradigm where the document is the unit of truth, so when we want a new kind of report our instinct is to create a new document, by hand, and maintain it forever.
That instinct costs the profession an enormous amount of time. Every status report you have assembled by hand from four other places was a view you computed manually, using your own attention as the query engine, at your hourly rate.
Once this lands, your questions change. You stop asking where is the spreadsheet that tracks X and start asking what would I have to record so that X becomes computable? You stop building reports and start building the record from which any report is nearly free.
Concretely: I do not maintain a list of urgent matters. I maintain matters, deadlines, and hearings, each recorded once, and “urgent” is a question asked of that data — regenerated every morning, never stale, because there is nothing to update. Move a deadline and the view moves. There is no second copy to forget.
That single 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 is also the shift that makes a firm wiki your AI can actually query work rather than becoming another folder nobody opens.
Three: APIs, and MCP
The third concept is connection.
An API — application programming interface — is the door a piece of software leaves open for other software. When your practice management system has one, there is a defined way for an outside program to ask it questions (what matters are open?) and tell it things (create this time entry). Every “integration” you have ever bought is one product talking to another product’s API.
For two decades, using an API required a developer, which is why you bought integrations instead of building them, and why your integrations only ever did what some product manager anticipated.
Now the model can use the API directly. The set of things your systems can do together is no longer bounded by a vendor roadmap. It is bounded by what you can describe.
MCP — the Model Context Protocol — is the newer piece and the one worth understanding, because it is a change in kind rather than degree. MCP is an open standard for handing a model a set of tools and telling it, in effect, here is 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.
The difference between an AI that can discuss your practice and one that can act on it is entirely this. It is the difference between a very well-read assistant locked in a room and one with keys to the office.
The conceptual payoff is a purchasing rule. The question is no longer does this vendor integrate with that vendor. It is does this system expose an API. If yes, you can wire it to anything, in any shape you want, without waiting on anyone. If no — if a vendor locks your data behind a UI with no programmatic door — that is now a serious strike, and it should weigh heavily. Your data being reachable is becoming more important than the tool being good. I have written separately about what it took to connect a model to a practice management system whose vendor had not implemented the standard; the code was the easy part.
Four: the interface is the last layer
There is a design discipline called separation of concerns. The version that matters here: storage, logic, and presentation are three different layers, and they should be built in that order.
Storage is where facts live. Logic is the rules operating on them — how a deadline is computed, what makes a matter urgent, when a bill is ready. Presentation is what a human sees: the screen, the page, the report.
Non-technical people almost always start at presentation, because it is the only layer they have ever seen. They describe the dashboard. And models are dangerously good at producing a beautiful dashboard, which is exactly why the first version looks extraordinary and the second falls apart. There was nothing underneath it.
Build in the right order and the interface becomes almost disposable. Sound data model, explicit rules, 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 Friday? Same data, same logic, three skins, and nothing important was ever in the skin.
That is the opposite of the SaaS bargain, where the interface was the product and your data was hostage inside it.
Five: the ones behind the concepts
A few more, less famous, that separate durable systems 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 are relying on for what. Deadline computation, conflict checking, and trust accounting must be deterministic code, because usually right is not 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, triaging inbound mail — probabilistic is fine, because a human reviews the output before it matters. Knowing which side of that line a task belongs on is a judgment about consequence, which is a thing lawyers are actually trained to make. It is the same judgment that separates verifying form from verifying truth.
Source of truth. For every fact, one system is authoritative and everything else is a copy. Write it down explicitly, because when two systems disagree — and they will — you need to have already decided which wins. Most firms have never made that decision consciously, and so resolve every conflict by argument, at the worst possible moment.
Events versus state. State is what is true right now. Events are the record of what happened. Most systems store only state, which is why you can never reconstruct why something changed. Keep an append-only log of events and you get an audit trail, an explanation, and answers to questions you did not know you would have. For a profession where the record is the whole ballgame, this should be intuitive, and mostly it isn’t.
Idempotency. An operation you can safely run twice without doing damage. It sounds like a technical footnote. It is 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. It is also, along with failures that say nothing, where quiet damage actually comes from.
What this means Monday morning
You are not going to become a software engineer and you should not try. None of this is meant to make you technical. It is meant to make you articulate — to hand you the small vocabulary that lets you direct a machine that does the technical part.
Start here. Write down the nouns of your practice and how they relate. Decide, for every important fact, which system owns it. Stop 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 disqualifying. And when you sit down to build, describe the data before you describe the screen.
There is a professional dimension to this too. Comment 8 to Rule 1.1 says competence includes keeping abreast of the benefits and risks of relevant technology. That has been quoted for a decade as a nudge toward using e-discovery software. It reads differently when the technology in question 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 — which, when you look at it squarely, is a drafting skill. We have been training for it the entire time.
The tools were never the moat. A clear, correct model of how your practice actually works is the moat. Software was only ever the way to write that model down, and it used to be too expensive to bother.
It isn’t anymore. Which means the cost of serving a client competently is about to fall for anyone willing to do the thinking — and that is 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.