Successor

A personalized guide for the executor of an estate

Comment

Inspiration

When a parent dies, one family member becomes the designated lead. They are usually named as executors in the will. They are usually the eldest child, the most organized sibling, or the one who happens to live closest. They have probably never done this before. They will probably not do it again for decades, if ever. And they are about to spend the next nine to eighteen months handling the estate while grieving, working, parenting, keeping a household running, and having their siblings ask them every two weeks why everything is taking so long.

I built Successor because that person has nowhere to turn. Estate attorneys cost three to ten thousand dollars and stay narrow on the legal filings. Books describe the process in the abstract but cannot adapt to the family's specific situation. Spreadsheet templates circulate informally and become unwieldy in weeks. Software in this space is either single-task utilities for funeral planning or expensive enterprise tools sold to financial advisors rather than to the family member doing the work. Nothing exists that holds the executor's hand through the full arc.

That gap is the project.

What it does

Successor is a guided workspace for the executor of a California estate. After a 15-minute intake conversation that captures the specifics of the situation, the application produces a personalized, sequenced roadmap of every task across the entire process, broken into the First Thirty Days, the First Ninety Days, the Middle Period, and the Closing Period. Each task is explained in plain language, including the required documents, typical timing, dependencies on other tasks, and a clear flag when an attorney consultation is warranted.

The application has four primary surfaces. The Roadmap is the executor's daily home screen. The Family Updates surface generates the standard executor communications (initial notification, periodic progress updates, difficult-conversation messages, closure announcements) tailored to the executor's situation, which the executor edits in their own voice before sending. The Documents vault holds every artifact the executor receives, parsed and linked to the relevant tasks. The Ask conversational layer lets the executor type any question in plain language and receive a grounded answer drawing on their specific circumstances and uploaded documents.

The application is positioned, throughout, as a research assistant rather than a substitute for legal advice. It does not generate court filings. It does not provide legal opinions. It tells the executor when they need an attorney, frequently and visibly, rather than hiding the limitation in fine print.

How we built it

I built Successor entirely on MeDo, Baidu's agentic full-stack app builder, with no code written by hand. The architecture includes a React frontend, a Node.js backend, Supabase for persistent storage and document storage, and ERNIE for the conversational layers, personalized roadmap generation, Family Updates drafts, and Ask responses.

The build proceeded across roughly eight MeDo sessions over three weeks, building the application incrementally, surface by surface. The first two sessions established the intake conversation, which is the credibility-bearing core because every other surface depends on the situation specifics it captures. The next two sessions built the Roadmap display. The fifth session built the Family Updates surface. The sixth built the Documents vault. The seventh built the Ask conversational layer. The eighth was a finishing pass that handled onboarding, navigation, empty states, the disclaimer treatment, and the closure flow.

The disclaimer treatment is worth noting because it ultimately shaped the application's character more than any other decision. The single sentence "Successor is a research assistant, not a substitute for legal advice. Consult an attorney for any matter requiring legal judgment" appears on the welcome screen, as a persistent banner on every page, and at the bottom of every Ask response. That repetition is deliberate. The application's value lies precisely in not pretending to be more than it is.

Challenges we ran into

The hardest single problem was striking the right tone for the Family Updates surface. Estate communications between siblings are emotionally loaded in ways most software cannot handle. A draft message that sounds legalistic alienates the family. A draft that sounds cheerful is out of step with the moment. A draft that sounds mournful is exhausting after the third one. The right register is calm, informative, and respectful, which is the voice an emotionally generous adult would use on a good day. I went through five rounds of multi-turn refinement on the prompt that produces these drafts before the output landed reliably. The breakthrough was framing the AI as drafting "what the executor would write themselves if they were having a good day," which consistently produced better results than any direct instruction about tone.

The second meaningful challenge was scope discipline. Estate law varies substantially by state, and the temptation to build a fifty-state application that covers every jurisdiction was constant. I held the line on California-only for the hackathon submission because covering one state well is strategically stronger than covering fifty states poorly, and because the demo video can close on a real, specific roadmap rather than on a generic template. The user-facing language throughout the application is explicit about this scope, with other states marked as coming soon.

A third challenge was the legal accuracy of the California probate task list. Procedural requirements change, thresholds get adjusted, and a roadmap containing incorrect information would immediately damage the application's credibility with any clinically literate judge. I verified the entire task list against a current edition of the California probate practice guide before submission, including the small estate threshold, the four-month creditor notice period, and the Inventory and Appraisal deadline.

Accomplishments that we're proud of

I am proudest of how little the application tries to do. There is no probate court e-filing integration. There is no attorney collaboration feature. There is no estate tax planning calculator. There is no white-label version for financial advisors. There is no analytics dashboard. Each of these is a reasonable feature in a mature product, and each one was deliberately left out. The result is an application an executor can understand in five minutes and use without instruction.

I am also proud of the closure flow. When the executor marks the final task on the Roadmap as complete, the application offers to generate the Final Accounting and produces a closure document that summarizes everything done throughout the process. This is the moment the application earns its place in the executor's life. It is the document the executor keeps. It is the chapter closing cleanly. Designing this flow with care, rather than treating it as a generic export, is what distinguishes Successor from a workflow tool.

What we learned

I learned that emotionally serious software requires emotionally serious design. The decisions that mattered most were not technical. They were decisions about tone, about what to leave unsaid, about when to defer to an attorney rather than answer, about which empty states were appropriate to a user in this situation. None of those decisions could be vibe-coded. Each required thinking about a specific person, in a specific moment of their life, and asking what they actually needed.

I also learned that the disclaimer treatment is the central architectural element of any application that touches legal territory. Most software treats disclaimers as a polish pass. For Successor, the disclaimer is the spine. The application is defined by what it refuses to do, as much as by what it does. Designing for that refusal, rather than around it, made the application more trustworthy than a more capable competitor that overpromised would be.

What's next for Successor

The most-requested feature from early users will be expansion to additional states beyond California. New York, Texas, Florida, and Illinois are the obvious next priorities given their populations and the documentation available for their probate codes. Each state expansion is a serious project rather than a configuration change, because the procedural sequence and the document requirements differ meaningfully. I expect to add one state per quarter rather than rushing nationwide coverage.

The second priority is integration with attorney collaboration. The application currently produces drafts the executor edits and uses themselves. A natural extension is letting the executor share specific drafts with their attorney for review, with the attorney's edits flowing back into the application. This is a real product feature rather than a flourish, because most executors do work with an attorney on the major court filings, and the friction of moving between the application and the attorney's email is a real source of delay.

The third priority is a closure archive that lets the executor designate someone to receive access to the application's records after closure, so that if they themselves face the executor process for another family member, or if their own family ever needs the records, the documentation persists. This extends Successor from a one-time tool to a multi-generational record, which is the natural product expansion if the project continues past the hackathon.

Built With

Share this project:

Updates