Building a Matter Management System From Scratch: What 200 Systems Taught Me

I have built roughly 200 legal systems over nine years, starting with no-code tools for whoever needed a working system and following the tooling forward through every generation up to agentic AI today, for solo lawyers and large business houses alike. Most of that work never gets written up, because a working system is quiet by design. Here is what actually held up across that many builds, and what I would tell anyone starting from a blank page.

1. Define your matter types before you open any software

The single most common mistake is opening a tool, Notion, Airtable, a CMS, and starting to build fields. Every time I have skipped the paper step and gone straight to software, I have rebuilt the structure at least once. Every time I have named the matter types and their fields on paper first, the software build has gone faster and needed almost no rework. The tool is the easy part. The naming is the actual work.

2. Start with your single highest-volume matter type, not all of them

A new system attempting to cover every matter type a practice handles on day one almost always stalls before launch, because the scope keeps growing. The builds that actually ship start with the one matter type that accounts for the largest share of the docket, get that pipeline fully working with real matters running through it, and only then extend to the next type. Depth before breadth, every time.

3. Get the pipeline running with no AI involved at all

This surprises people. I always build the plain structural pipeline, matter, actions, time, team, evidence, research, as a working system before adding a single AI feature. A system that only works because an AI model is doing the organising underneath it is not actually a system, it is a demo with a dependency. Once the structure holds on its own, AI has something real to grip and speeds it up. Add AI to a structure that does not exist yet and you get expensive chaos at higher speed, not a functioning system.

4. Add one computed module at a time

A computed module, a dashboard, a status rollup, a deadline tracker, is where builds get ambitious and then break. Add too many at once and nobody can tell which module produced a wrong number when something looks off. Building and verifying one module before starting the next takes longer up front and saves enormous time in debugging later.

5. Build evidence anchoring in from the first module, not as a later fix

Every claim in every draft should trace back to its source document, page and paragraph, as structure rather than memory. Retrofitting that discipline into a system that has already been running for a year is far harder than building it in from the first computed module, because by then habits have formed around not citing sources, and habits are the hardest thing in any system to change.

6. Track real completion time, AI-adjusted, before you reprice anything

A system that does not measure how long its own actions actually take cannot tell you anything useful about pricing. I log completion time for a full cycle, adjusted for whatever AI assistance is actually in use, before touching a fee structure. Guessing at durations produces fixed fees that either lose money on the outliers or overcharge the routine matters, and a practice usually cannot tell which is happening until the numbers are in front of them.

7. Write the exception path before the happy path

Every workflow I have documented for automation gets the standard sequence written down easily. What separates a system that survives contact with real matters from one that does not is whether the exception path, the missing document, the client who goes quiet, the deadline that moves, got written down with the same care. Machines cannot handle what was never described, and the exception path is where most matters actually deviate from the plan.

8. Separate the doer from the reviewer, explicitly, for every action

Vague ownership is the most common reason a system stops being trusted. When an action's status is wrong and nobody can say whose job it was to catch that, people stop relying on the system and go back to checking manually, which defeats the entire purpose of building it. Naming a doer and a reviewer for every action, human or machine, is cheap to do at build time and expensive to add later.

The pattern underneath all of it

Every one of these lessons is really the same lesson stated eight different ways: name the process on paper before a single line of software gets written for it. That line has been true across 200 builds regardless of practice area, firm size or which decade's tooling I was using. I built the Matter Starter System as the pre-wired version of exactly this spine, matters, parties, deadlines, documents, tasks and money, structured the way I install it for clients, so a practice can skip straight to a working system without repeating the mistakes above one at a time.