Starting a Matter Management System From Zero: A 30-Day Plan

People ask me for a lessons-learned list after 200 builds, and I have written that piece. What people ask for less often, but need more, is the plan itself, not principles, an actual calendar. This is that calendar. Thirty days, four weeks, from a practice with nothing structured to a working matter spine running real matters through it.

This assumes you are building it yourself or with one other person, not commissioning a full engagement, and it assumes you are starting from your single highest-volume matter type, not trying to cover the whole practice on day one. If you try to cover everything at once, you will not finish in thirty days, or possibly at all.

Week one: naming, no software

Days one through three are entirely on paper. Name your highest-volume matter type precisely, then write the action sequence for it, every discrete step from open to close, in order, including the exceptions, because exceptions are where most self-led documentation efforts quietly give up. Days four and five, name the six primitives against that matter type specifically: what counts as the matter, what actions repeat, what deadlines and durations matter, who touches which action, what evidence gets relied on, what research questions recur. Do not open any software this week. Every hour spent naming saves several hours of rebuilding later.

By the end of week one you should have a written, ordered action list for one matter type and a rough sense of your six primitives against it. That document, not a database, is the actual foundation.

Week two: the spine, structurally

Now open the tool, whether that is Notion, the Matter Starter System, or something else. Build the core relational structure: a Matters database as the hub, with Actions, Deadlines, Team, Evidence and Research as separate, linked databases rather than fields crammed into one table. Populate the action library for your chosen matter type as a template that generates automatically for a new matter of that type. Do not build views yet, and do not add automation yet. This week is purely structural: does the spine hold together when you look at it, and can a stranger understand a matter's status from it in ten minutes.

By the end of week two you should have a working, empty structure: real relations, a real action template, no live matters running through it yet.

Week three: live matters, no automation

Take three to five real, currently open matters of your chosen type and migrate them into the new structure by hand. Do this deliberately without automation, because the point of week three is to find every place the structure you designed on paper does not survive contact with a real, messy, in-progress matter. It will not survive perfectly. Something will not fit. Note every gap rather than patching it invisibly, because those gaps are the actual data you need before you build anything more automated on top of the structure.

By the end of week three you should have real matters living in the system, a short list of structural gaps you found, and enough confidence in the spine to trust it for new matters going forward.

Week four: close the gaps, then stop

Fix the specific gaps you found in week three, and only those. Do not use week four to add features you thought of along the way, a client portal, an automation, a second matter type. Scope creep in week four is the single most common way a thirty-day build turns into a six-month one. Close what you found broken, open your next new matter of that type directly into the finished structure, and stop.

By day thirty you should have one matter type fully running on a real spine, with real matters in it, built and proven rather than theorized. That is a genuinely different achievement from a beautiful empty template, and it is the version that actually survives past month three.

What to do when a week runs long

Some week will run long, almost always week one, because naming a process precisely is harder than it sounds when you are the person who already knows it by instinct. If week one bleeds into week two, let it, and compress week four instead, since week four is the flexible week, closing whatever gaps actually surfaced rather than a fixed list of tasks. What should never compress is the naming step itself. A rushed week one produces a spine that looks finished and is not, and the rework it costs later is larger than the days you saved skipping it.

What thirty days does not include, on purpose

It does not include a second matter type, and it does not include AI automation layered on top. Both of those are real next steps, and both of them are safer and faster once the plain structural pipeline is proven with one matter type first. A system that only works because AI is doing the organizing underneath it is not a system yet, it is a demo with a dependency, and the sequence matters more than the ambition.

If you would rather not spend week two building the spine field by field from a blank page, the Matter Starter System is the same structure I install in client builds, pre-wired, with the installation walkthrough that gets you from a blank page to a first matter in a day rather than a week. It does not replace week one. Naming your process on paper is still the part nobody can do for you.