Planning Reference · Fresh Rebuild
Household Ledger Platform
10-Step Rebuild Roadmap
A visual guide for moving from the legacy Brown Family Legacy repository into a clean Household Ledger Platform without allowing old code, folders, authority rules, or database structure to define the new product.
Status: Planning reference only. This page does not replace a Phase 0 Product Map, owner ruling, or later durable product authority.
Definition breadthWhole platform
Implementation strategyPrioritized waves later
Legacy ruleMuseum, not blueprint
1
Review the Dev Command method
METHOD
Adopt the build discipline: authority first, HTML before React, explicit gates, evidence, owner acceptance, and cheap-to-expensive sequencing.
CopyThe method and organizational discipline.
Do not copyDev Command's product architecture.
2
Pass 0A — Inventory and classify legacy truth
SOURCE EVIDENCE
Inspect brown-family-legacy as evidence. First identify source families, then group by fresh domain, then classify individual material.
PreserveCurrent truth · visual authority · workflow source · historical reference.
Do not assumeRecency, old authority labels, implementation, or schema automatically survives.
3
Draw the Household Ledger Platform box
PHASE 0 · PLATFORM
Define the whole platform: canonical identity, purpose, primary users, the main Household Ledger application, eight bounded applications, shared responsibilities, and explicit exclusions.
Main Household LedgerHousehold + Core together form the central application.
8 bounded applicationsIndependent domains inside one platform.
4
Draw the main Household Ledger application box
MAIN APP
Define Household and Core as two experience groups inside one main application rather than separate products.
HouseholdOverview · Daily Command · Communications · Vision
CoreRecords · Cash Flow · Matters · Assets · Accounts · Binder
5
Draw all eight bounded application boxes
WHOLE PLATFORM
Each application receives its own purpose, ownership, exclusions, major destinations, conceptual routes, handoffs, and historical truth worth preserving.
Grocery
Health
Tax
Estate Planning
Household Jobs
Careers
Library
Gallery
Phase 0 target: 1 platform Product Map + 1 main-app Product Map + 8 bounded-app Product Maps = 10 maps.
6
Resolve ownership seams
HANDOFF MATRIX
Build one platform ownership and handoff matrix so shared concepts cannot quietly acquire competing homes.
Identity→Documents→Actions→Accounts→Assets→Permissions
Question for every seam: Who owns it? Who may read it? What is the explicit handoff?
7
Resolve owner rulings and accept Phase 0
OWNER GATE
Only real product-boundary decisions should require owner intervention. Mechanical classification and document housekeeping should not.
Before closingEvery destination has one owner and every shared responsibility is deliberate.
Close conditionExplicit owner acceptance of the complete Phase 0 set.
8
Phase 1 — HTML Everything
VISUAL AUTHORITY
Prototype the whole platform before React begins: shared shell, main Household Ledger, all eight apps, desktop, phone, and important special states.
Legacy prototypesReuse unchanged · adapt · reference only · reject.
EvidenceHTML authority index + visual-state matrix.
9
Bootstrap Next.js and translate with React Fidelity
IMPLEMENTATION
Only after Phase 1 is accepted does the fresh runtime begin. Translate the accepted HTML into Next.js/React/TypeScript using mock data.
BuildRoutes · components · navigation · responsive shell.
RuleReact translates approved HTML; it does not redesign it.
10
Accept React, define behavior, then earn the database
BEHAVIOR → DATA
Compare HTML to React, obtain visual acceptance, define the Interaction / State Contract, then define the Data Contract. Only then create the fresh Supabase project, schema, migrations, and selective legacy-data migration path.
HTML ↔ React audit→Owner visual acceptance→Interaction / State Contract→Data Contract→Fresh Supabase