My Top 10 Legal Practice Systems I'd Build First If Starting Over

People occasionally ask what I would build if I were starting a practice's systems from nothing, no legacy software, no existing habits to work around, and had to prioritize. This is that list, in order, with the reasoning for the order, because the sequence matters at least as much as the individual systems do.

1. The matter spine

Everything else on this list depends on this existing first. One relational structure, matters as the hub, actions, deadlines, team, evidence and research as linked databases around it. Building anything else before this exists means rebuilding it later once the spine finally gets designed, which I have watched happen more times than I can count.

2. Your highest-volume matter type's action library

Not every matter type. The one that accounts for the largest share of your docket. Write the action sequence for it as an installable structure, not a memory. This is the system that pays for itself fastest, because it is the one running most often.

3. A real intake and referral system

Intake is where practices leak the most revenue, invisibly, before it shows up on a P&L line. I would build this third rather than first because an intake system needs somewhere structured to hand a converted enquiry off to, and that only exists once the spine and the first matter type are already in place.

4. Deadline tracking, calculated from triggering facts

Once matters and actions exist as structure, deadlines should not be a field someone fills in manually, they should calculate from a triggering fact already in the matter record. I put this fourth because it needs the spine and the action library underneath it to actually function; built in isolation, it is just another calendar that only knows what it is told.

5. Evidence anchoring for anything AI-assisted

If AI is touching drafting at all, and by this point in a build it usually is, evidence anchoring needs to exist before AI-assisted drafting becomes routine, not after a hallucinated claim nearly makes it into a filing. I would rather build this early and have it feel like overkill for a few months than build it late as damage control.

6. A billing structure tied to the matter, not separate from it

Time entries, invoices and follow-ups that relate directly to the matter record rather than living in a disconnected billing tool. This is sixth, not first, because a billing system built before the matter spine exists inevitably gets rebuilt once the spine finally arrives, the same lesson as item one, applied to a different database.

7. Duration data, tracked deliberately from day one

Not a separate system, a discipline layered onto the action library: track how long each action of a given type actually takes, from the first matter onward. Most practices only start wanting this data once they are trying to price a fixed fee and realize they have none. Starting the tracking early means the data exists by the time you need it, instead of six months of catch-up once you finally do.

8. A research knowledge base that compounds

Once matters are generating real research questions on a real cadence, capturing the answers as a growing, searchable resource rather than letting each one evaporate into a matter folder. Seventh rather than first because it needs a critical mass of matters generating real questions before the compounding effect is visible enough to justify the discipline of maintaining it.

9. Client communication templates tied to matter state

Status updates and routine communications drafted from the matter's actual current state rather than typed from scratch each time. This is close to the bottom of the list on purpose, it is a genuine quality-of-life improvement, not a structural necessity, and building it before the systems above exist means it has nothing real to pull from.

10. A second matter type

Only once the first is fully proven. Extending the spine to a second matter type is genuinely fast once the first one has already tested the structure against real, messy matters. Attempting a second matter type before the first is proven is the single most common way a self-led build stalls, because the scope keeps growing before anything has actually shipped.

Why the order matters more than the list

Every item on this list, built in isolation or in a different order, produces a weaker version of itself. The spine has to come first because everything else attaches to it. The single matter type has to come before a second because depth before breadth is the difference between a build that ships and one that stalls. This is not a preference, it is the sequence I would run again if I started from nothing tomorrow.

If you would rather install this structure practice-area by practice-area than build each layer from scratch, the Practice Pack Blueprints cover all twenty-two practice areas with the stages, vitals, deadline logic and document categories already worked out, the same content this list describes in principle, ready to install rather than design from a blank page.