Let me start by giving Clio its due, because what follows is not a complaint and the company has not done anything wrong.
Clio, and the category it created, is probably the single best thing that happened to small-firm practice in my professional lifetime. Before it, a solo or three-lawyer firm had two options: an enterprise practice management system priced for a hundred seats and installed by a consultant, or a filing cabinet, a paper calendar, and a legal pad for time. The first was unreachable. The second is where most of the profession actually lived, and it is where most malpractice claims were born.
What the cloud practice management vendors did was take a genuinely enterprise-grade data model — matter-centric organization, contact relationships, time capture tied to the matter, trust accounting with a real ledger, calendaring with court rules, document association, a conflicts database — and sell it for the price of a decent dinner per lawyer per month. They made a one-lawyer firm operationally credible. They made trust accounting something a solo could actually get right. They shipped an API when almost nobody in legal software would. Whatever comes next owes them the entire template, and I say that as someone who has run a firm on their software for years and still does.
Now the uncomfortable part.
What you are actually renting
Strip the interface off any practice management system and you find three things.
A relational database. A set of tables and the relationships between them. Contacts. Matters, each belonging to a contact. Activities — time entries and expenses — each belonging to a matter and a user. Bills, built from activities. Tasks, each with a due date and an assignee. Calendar entries. Documents, associated with matters. Notes. Custom fields bolted onto several of the above. Trust and operating ledgers. That is the whole model, and if you have used the software for a year you could sketch it yourself on a napkin.
A set of views over that database. The matter dashboard. The billing worksheet. The unbilled-time report. The productivity chart. The calendar. The task list. None of these are separate information. They are one body of data, presented from different angles — the distinction I wrote about last time, and the reason a practice management system feels like a dozen products when it is really one.
An API. A defined door for other software to read and write that data programmatically. Clio’s is a documented REST API with OAuth authorization and, by default, a rate limit measured in tens of requests per minute. It is the reason the ecosystem of integrations exists at all.
That is the product. A schema, some views, and a door.
In 2011 that combination was worth an enormous amount of money, because assembling it yourself meant hiring developers, and hiring developers meant a budget no small firm had. You were not really paying for the database. You were paying for the fact that you could not build a database.
What changed
You can build the database now. In an afternoon, describing what you want in English, without writing code.
I want to be precise about what that claim does and does not mean, because there is a lot of breathless nonsense in this area and I would rather be useful than exciting.
Here is what is genuinely true. If you sit down with a capable model and say build me a SQLite database with tables for contacts, matters, activities, bills, tasks, calendar entries, and documents, with these relationships, and these fields, and here is how my practice actually defines a matter — you will have a working, correct, indexed schema in under an hour. Ask for a web interface over it and you will have one by dinner. Ask for the unbilled-time view, the matter dashboard, the deadline list, and each takes minutes, because a view is just a question asked of data that already exists.
The thing that used to be the entire cost — turning a clear description of a data model into working software — is now nearly free. What remains expensive is having the clear description, and that part was always yours. No vendor ever knew your practice. They shipped an average of ten thousand practices and let you fill in custom fields around the edges.
Why yours ends up more powerful
This is the part people underestimate. The homemade version is not a scrappy approximation of the commercial product. On the dimensions that matter operationally, it is substantially better, for five structural reasons.
Your schema matches your practice, not the average of ten thousand practices. In my work a matter sometimes has two clients with a joint-representation memo governing the relationship. In a commercial system that is a custom field and a note. In your own schema it is a real relationship with real integrity rules, which means you can query it — show me every matter with more than one client where the joint-representation disclosure has not been signed. That question is unanswerable in a system that does not model the thing.
Every view is yours. Vendors ship the reports most customers want. You want the report you want, which is usually some intersection nobody built: matters with no activity in twenty-one days where the client has called twice, or contingency files where non-billable time has passed some threshold. In your own database those are each a few minutes of work, and once built they never go stale.
The connectors reach anything. This is the multiplier, and it is where the difference stops being incremental. A commercial system integrates with what its partnership team negotiated. Your database connects to anything with an API — your accounting ledger, your email, your calendar, your phone system, your e-filing service notices, your scanner, your document storage, a chat channel, a local model running on hardware in your office. And through MCP, an AI assistant gets tools over all of it: read the matter, check the ledger, draft the letter, file it, calendar the deadline. Not a chatbot that discusses your practice — one that operates it. I have written about what it took to build that connector against a vendor’s API, and the honest summary is that going through someone else’s door is most of the work. Owning the database removes the door.
No per-seat economics, so automation is free at the margin. When every user costs a monthly fee and every integration is a subscription, there is a real price to automating a small annoyance, so you don’t. When the marginal cost of another view, another automation, another user is zero, you automate everything that annoys you. That compounds in a way that is hard to appreciate until you have lived in it for six months.
Your AI can query the data directly. This is the underrated one. An assistant working through a rate-limited API, paging through JSON, is doing archaeology. An assistant that can run a query against your own database answers portfolio-level questions in a second — which open matters have a deadline in the next fourteen days and no filed document since June — that no commercial reporting module will ever offer, because that question is specific to you.
Ten times more powerful is not marketing. It is what happens when the data model fits, the views are unlimited, and everything in the office can talk to everything else.
The honest ledger
Now the part I would want to read before I did this, and the part most enthusiasm on this subject leaves out.
Trust accounting is not the place to start, and may not be a place to go at all. Rule 1.15 requires that funds of clients and third persons be held in identifiable trust accounts and that every lawyer in private practice maintain books and records sufficient to demonstrate compliance, on a current basis, preserved for years. That is a bright-line, license-threatening obligation, and the standard is not my system usually reconciles. A commercial system that has been audited, that produces the reports a disciplinary investigator expects, and that has a vendor standing behind it is worth real money for this specific function. My advice, and my own arrangement: keep the ledger where it is compliant and build everything else around it.
You are now the vendor. Backups, restores, encryption, access control, device loss, and the answer to what happens when a laptop is stolen — those were on somebody’s ops team and are now on you. Rule 1.6 does not care that you built it yourself. The mitigations are real and boring: automated encrypted backups, tested restores, full-disk encryption, a written note of where everything lives.
There is no support line. When it breaks at 11 p.m. before a filing, the escalation path is you. In practice this is less frightening than it sounds — you can ask the model that built it to fix it — but it is a genuine change in posture.
Succession is a professional obligation, not an IT problem. If you are hit by a bus, someone has to be able to open your files and serve your clients. A commercial system solves this by existing independently of you. A homemade one solves it only if you deliberately make it solvable: standard formats, documented schema, plain-text exports, and a named person who knows how to get in. Do this before you build the second feature, not after.
Migration is where the time actually goes. The schema is an afternoon. Getting years of existing data out, mapped correctly, deduplicated, and reconciled is the real project. Budget for that honestly.
None of these are arguments against building. They are the reason the sensible path is not a cutover.
The path I would actually take
Not a switch. A gradual shift in where the truth lives.
Stage one: mirror. Build the schema and populate it read-only from your existing system’s API on a schedule. You change nothing about how you work. Your commercial system remains the source of truth. What you gain immediately is a queryable copy of your entire practice — which is enough to build views your vendor never shipped, and enough for an AI assistant to answer real questions about your portfolio. The risk here is essentially zero, and the payoff is immediate. Most firms could stop here and be better off.
Stage two: views and connections. Build the reports you always wanted. Wire in the systems your vendor never integrated with — your phone provider, your e-service notices, your accounting, your document storage. Still no writes to anything authoritative. This is where the “ten times” starts to be visible.
Stage three: originate new data. Start recording things your commercial system has no model for. In my practice that has meant strategic observations, judge and opposing-counsel patterns, matter posture, closure debriefs — a whole layer of institutional knowledge that has no field anywhere in a commercial product. Nothing was replaced; something new exists.
Stage four, if ever: selective replacement. Move individual functions when your version is demonstrably better and you have run both in parallel long enough to trust it. Some functions — trust accounting, most likely e-filing — you may rationally never move.
That path is safe at every step, useful from the first one, and never requires a leap of faith. It is also, notably, not a decision you have to make all at once, which is the opposite of how software purchases have always worked.
What this is really about
The reason I write this section down at all is arithmetic about access rather than enthusiasm about tools.
The binding constraint on representing people who cannot afford a lawyer has never been talent or willingness. It is that the overhead of running a competent practice sets a floor under what an hour has to cost, and that floor prices out an enormous number of people with real legal problems. Every fixed monthly cost per user, every integration subscription, every hour spent reconciling systems that disagree is part of that floor.
What is happening right now is that a large piece of that floor is dissolving. Not because software got cheaper to buy, but because it got nearly free to make — and the thing that made it expensive was never the typing. It was the translation from someone who understands the work into something a machine executes. That translation is exactly what a lawyer who can describe a data model can now do directly.
Clio earned its place by making a competent solo practice possible at all. The next move is not to resent the toll; it is to notice that the road is now free to build. What you do with the difference is the only part that was ever interesting.
Sources
- Minn. R. Prof. Conduct 1.15 (safekeeping property; trust accounts; books and records maintained on a current basis)
- Minn. R. Prof. Conduct 1.6 (confidentiality of information)
- Clio API v4 documentation — REST, OAuth 2.0 authorization code grant, default rate limit 50 requests/minute at peak
- Model Context Protocol — open standard for giving a model tools over external systems
General commentary on practice management. Not legal advice, not ethics advice, and not a recommendation for or against any vendor. Nothing here should be read as a statement that any product is unsuitable — the trust-accounting caution above is deliberate and should be taken seriously. No client information appears in this article; all examples are generic.