Building an asset for my family that works without me.
A few weeks ago I started listing every legal document, account, policy, and entity that matters to my family. Not for a client. For my own family. I wanted to see the whole picture at once, and I wanted to write it down in a form that someone who is not me could read.
The exercise is ongoing. What has surprised me is how much of it was only in my head. What started as a list has grown into a system. The system has a long way to go.
I have been building things for other people for a long time. Client structures, entity architectures, cash-flow systems. A firm (444 Growth Partners) whose entire thesis is that a business should work because of its structure, not because of the founder. One line: if it depends on you, it doesn’t transfer.
What I had not fully built was a version of that for my own life.
It started as an exploration of the capabilities I had built around my CPE knowledgebase (the system I describe in A System for What I Know). Could I extend the same architecture into a virtual multi-family office platform? Eight operational frameworks, tiered rollout, invitation model, target scale parameters. All the normal commercial scaffolding around a service offering. Some of that framing came from me; some came from leaning on AI scoping recommendations.
I had a realization while I was out on my bike for a training ride…I wasn’t trying to build a multi-family office. I was trying to build something for my own family. The commercial scaffolding was distracting me from the thing that actually mattered.
Once I named it, the architecture simplified. The original outline had eight operational frameworks. Framework eight was succession planning. Under the handover reframe, succession stopped being one framework among eight and became the thing the other seven exist to serve. The system is one operating system for one family. Mine. The seven components are how it does the work; succession is why.
The constraint that makes this project different from everything else I have built is the handover test. Every architectural decision (where data lives, how playbooks are written, what the AI layer does, what voice the README uses) gets resolved against one question: when this is handed to my wife, or to an executor, or to one of my adult children via a README, does it still work?
Day-to-day usefulness for me falls out of that filter automatically. The reverse is not true. If I design for my own use first, I end up with something that only I can operate. If I design for handover first, I end up with something that works for me and survives me.
There are three layers in the design.
A data layer: entity map, account inventory, document index, policy register, advisor roster, obligations calendar. Written in plain text and spreadsheets, so my wife can open it in Excel without needing any tool I have chosen.
A playbook layer: one operating procedure per recurring event. Each playbook explains what to do. It also explains why I decided it that way, so someone picking it up can decide whether to continue the approach or change it with open eyes.
An orchestration layer: an AI assistant that can read the data, run the playbooks, and answer questions about the family’s situation. The AI is useful. It is also optional. Everything underneath it has to work without it, because ten years from now AI tooling will look nothing like it does today.
The first deliverable was the README. The README is the navigational spine. It’s what gets handed over. It tells a reader: “here’s what this is, here’s how to find what you need, here’s who to call first.” The README is the spec. The data layer, the playbooks, and the orchestration layer all build in parallel against it. Each piece earns its place by filling a section of the README adequately. If the README cannot be followed to operate everything, the system is not done yet.
The piece of this work that is hardest is the first 72 hours letter to my wife.
It is a short document in plain language, with no legal training assumed: who to call first; what can wait a week; what funds are immediately accessible for at-need expenses; what the kids need to know and when; what stays the same automatically; where the will is; where the safe-deposit key is.
It is not a hard document to write in the sense of craft. The hardness is in facing what it is for.
I am writing it anyway.
There is a word I am careful with because it carries baggage it does not need to carry. The word is frequency.
The word I want is the literal one. Frequency in the sense of what I transmit beyond myself. Not a metaphysical claim. A mechanical one. The system I am building is designed to carry my judgment, my preferences, and my care for my family forward in time when I cannot do it directly. If it works, it is because I found a way to transmit the thing I know outside of myself, into a form that does not require me to be in the room.
That is the durable asset, turned inward.
I am not done. The entity tree is in flight. The advisor roster is being inventoried. The legal authority map is taking shape. The first 72 hours letter is on the near horizon. Beyond those, the playbooks. Beyond those, the orchestration layer on top. Each piece compounds on the one before it. Each piece has to earn its way into the system by being navigable without me.
Writing this down in public is part of how I keep myself honest. If I am going to spend the next year building this, I would rather be watched doing it than announcing it when it is finished.
It is the same principle the firm runs on, turned toward my own house instead of a client’s. A thing that depends on one person isn’t built yet. It’s just being carried.
I have been building things for other people that do not depend on them. It is time to build one for my own family that does not depend on me.