First, Clio deserves its due. What follows isn’t a complaint, and the company hasn’t done anything wrong.
Clio, and the category it created, is probably the best thing that happened to small-firm practice in my career. Before it, a solo or three-lawyer firm had two choices: 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 out of reach. The second is where most of the profession actually lived, and it’s where most malpractice claims were born.
What the cloud practice management vendors did was take a real enterprise-grade data model — matters at the center, 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 look and run like a real operation. 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 whole template, and I say that as somebody who’s run a firm on their software for years and still does.
Now the uncomfortable part.
What you’re actually renting
Pull 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, tied to matters. Notes. Custom fields bolted onto several of the above. Trust and operating ledgers. That’s the whole model. If you’ve used the software for a year, you could sketch it 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 is separate information. They’re one pile of data, looked at from different angles — the distinction I wrote about last time, and the reason a practice management system feels like a dozen products when it’s really one.
An API. A defined door for other software to read and write that data. Clio’s is a documented REST API with OAuth authorization and, by default, a rate limit measured in tens of requests per minute. It’s the reason the whole ecosystem of integrations exists.
That’s the product. A schema, some views, and a door.
In 2011 that combination was worth a fortune, because building it yourself meant hiring developers, and hiring developers meant a budget no small firm had. You weren’t really paying for the database. You were paying because you couldn’t build one.
What changed
You can build the database now. In an afternoon, describing what you want in English, without writing code.
There’s a lot of breathless nonsense in this area, so here’s exactly what I mean and what I don’t.
Here’s what’s true. 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 — and you’ll have a working, correct, indexed schema in under an hour. Ask for a web interface over it and you’ll have one by dinner. Ask for the unbilled-time view, the matter dashboard, the deadline list, and each one takes minutes, because a view is just a question asked of data that’s already there.
The thing that used to be the entire cost — turning a clear description of a data model into working software — is now close to free. What’s still 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
People underestimate this part. The homemade version isn’t a scrappy knockoff of the commercial product. On the things that matter day to day, it’s a lot better, and there are five reasons why.
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’s a custom field and a note. In your own schema it’s 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 hasn’t been signed. You can’t even ask that question in a system that doesn’t model the thing.
Every view is yours. Vendors ship the reports most customers want. You want the report you want, which is usually some combination 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 each of those is a few minutes of work, and once it’s built it never goes stale.
The connectors reach anything. This is the multiplier, and it’s where the difference stops being small. A commercial system connects to whatever 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. That’s an assistant that runs your practice, not a chatbot that chats about it. I’ve written about what it took to build that connector against a vendor’s API, and the short version is that getting through somebody else’s door is most of the work. Own the database and there’s no door.
No per-seat pricing, so the next automation costs nothing. When every user costs a monthly fee and every integration is another subscription, automating a small annoyance has a real price, so you don’t do it. When another view, another automation, another user costs zero, you automate everything that bugs you. That compounds in a way you won’t appreciate until you’ve lived with it for six months.
Your AI can query the data directly. This one’s underrated. An assistant working through a rate-limited API, paging through JSON, is digging for artifacts. An assistant that can run a query against your own database answers questions about your whole practice in a second — which open matters have a deadline in the next fourteen days and no filed document since June — and no commercial reporting module will ever offer that, because the question is yours.
Ten times more powerful isn’t marketing. It’s what you get when the data model fits, the views are unlimited, and everything in the office can talk to everything else.
What it actually costs you
Here’s the part I’d have wanted to read before I did this, and the part most of the cheerleading on this subject skips.
Trust accounting is not the place to start, and maybe not 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 keep books and records sufficient to demonstrate compliance, on a current basis, preserved for years. That’s a bright-line obligation your license rides on, and the standard isn’t my system usually reconciles. A commercial system that’s been audited, that produces the reports a disciplinary investigator expects, and that has a vendor standing behind it is worth real money for this one job. My advice, and what I do myself: keep the ledger where it’s compliant and build everything else around it.
You’re the vendor now. Backups, restores, encryption, access control, lost devices, and the answer to what happens when a laptop gets stolen — that used to be somebody’s ops team. Now it’s you. Rule 1.6 doesn’t care that you built it yourself. The fixes are real and boring: automated encrypted backups, restores you’ve actually tested, full-disk encryption, a written note of where everything lives.
There’s no support line. When it breaks at 11 p.m. before a filing, the escalation path is you. In practice that’s less scary than it sounds — you can ask the model that built it to fix it — but it’s a real change in who’s on the hook.
Succession is a professional duty, not an IT problem. If you get hit by a bus, somebody has to be able to open your files and serve your clients. A commercial system handles that by existing apart from you. A homemade one handles it only if you set it up to: standard formats, a documented schema, plain-text exports, and a named person who knows how to get in. Do that before you build the second feature.
Migration is where the time really goes. The schema is an afternoon. Getting years of existing data out, mapped right, deduplicated, and reconciled is the real project. Budget for it.
None of that is a reason not to build. It’s the reason you don’t flip a switch.
What I’d actually do
Don’t switch. Move where the truth lives, a little at a time.
Stage one: mirror. Build the schema and fill it read-only from your existing system’s API on a schedule. You change nothing about how you work. Your commercial system stays the source of truth. What you get right away is a copy of your whole practice you can query — enough to build views your vendor never shipped, and enough for an AI assistant to answer real questions about your caseload. The risk is basically zero, and the payoff is immediate. Most firms could stop here and come out ahead.
Stage two: views and connections. Build the reports you always wanted. Wire in the systems your vendor never connected to — 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 show.
Stage three: start keeping new data. Record things your commercial system has no place for. In my practice that’s meant strategic observations, judge and opposing-counsel patterns, where each matter stands, closure debriefs — a whole layer of institutional knowledge with no field anywhere in a commercial product. Nothing got replaced. Something new exists.
Stage four, if ever: replace pieces. Move a function over when your version is clearly better and you’ve run both side by side long enough to trust it. Some functions — trust accounting, probably e-filing — you may never move, and that’s a sensible call.
That path is safe at every step, useful from the first one, and never asks for a leap of faith. It also isn’t a decision you have to make all at once, which is the opposite of how buying software has always worked.
What this is really about
I write this section because of math about access, not because I’m excited about tools.
The real limit on representing people who can’t afford a lawyer has never been talent or willingness. It’s that the overhead of running a competent practice puts a floor under what an hour has to cost, and that floor prices out a huge number of people with real legal problems. Every fixed monthly cost per user, every integration subscription, every hour spent reconciling two systems that disagree is part of that floor.
Right now a big piece of that floor is dissolving. Not because software got cheaper to buy. Because it got nearly free to make — and the expensive part was never the typing. It was translating from somebody who understands the work into something a machine can run. A lawyer who can describe a data model can now do that translation directly.
Clio earned its place by making a competent solo practice possible at all. The next move isn’t to resent the toll. It’s to notice the road is free to build now. 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.