Family Budget — A Shared Household Budget for Daily Entry and Month-End Close
Personal product · owned product design, backend, data model, automation, and responsive UX end to end
2026-08-14 — present
A shared household budget that turns daily income and expense entry, joint and individual ownership, purpose accounts, and recurring plans into one month-end decision.
The user journey in the implemented product UI
Family Budget
Decide the month on the dashboard, capture daily activity on mobile, and confirm expected items before posting them to the ledger. Every screen uses the same canonical UI package as the operational product with synthetic data.
Core system design
Operational source of truth
Application-owned writes
Historical sheets remain a read-only import boundary
Before: Spreadsheet-led entry and interpretation
Plan ≠ actual
Rule · occurrence · actual separation
Expected, actual, and variance stay independently traceable
Before: Expected rules confused with actual income and spend
Duplicate and ambiguity control
Link first · confirm · read back
Partial success and reopen remain explicit
Before: Risk of creating a new actual despite an existing candidate
Operational product boundary and public evidence
Household members and an approval-gated assistant use the operational ledger through an authenticated API. The historical spreadsheet is a read-only import boundary, while the synthetic public demo is secondary evidence for screen contracts.
Representative reconciliation flow
A monthly occurrence looks for an existing actual first. After confirmation it links or creates, then updates expected, actual, and variance through a transactional write and read-back.
Problem Solving
Treating planned items as actual ledger events would duplicate income and spend and erase explainable monthly variance.
Separated recurring rules as plan truth, monthly occurrences as reconciliation units, and transactions or purpose deposits as actual fact truth.
The dashboard derives expected, actual, and variance independently while preserving the contract that a plan is not an actual transaction.
When realizing income or spend, missing an existing ledger candidate could duplicate the same event as a new transaction.
Find the occurrence and candidates by name, owner, and month; when a candidate exists, propose linking before creation and require an explicit choice for a new actual.
Link, create, skip, and reopen paths remain traceable in one reconciliation flow without silent duplication.
If automation collapsed a successful write and failed refresh into one error, retrying could duplicate a record that already succeeded.
Preview the request for approval, then read back the ledger and dashboard after writing while reporting partial success and verification failure as distinct states.
The workflow re-reads current truth instead of blindly retrying, and can safely recover by reopening the occurrence when needed.
Domain model and user flows
Public-safe diagrams explain the relationship between plan, occurrence, and actual, plus the mobile-entry and desktop-review flows.
Operating limits
Claim → public evidence
Each claim links directly to public code, tests, or CI rather than only to a repository home page.
26 canonical UI files
How are the UI source of truth and allowed seams pinned?
Browser-local read/write
Where do synthetic storage, reads, and reset run?
UI and data-source separation
How is the public adapter injected into shared UI?
Public-boundary checks
Which executable checks block drift and forbidden patterns?
Live synthetic product flow
Can the public screens be inspected without login?
Project Description
Family Budget goes beyond recording transactions. A non-developer household member can capture daily spending on mobile, while the shared desktop workspace reviews the ledger, purpose accounts, assets, and expected items month by month. The dashboard combines expected income, spending, savings, actual activity, and incomplete checks into one month-end decision. Underneath, recurring rules (plans), monthly occurrences, and actual ledger events stay separate, and linking an existing actual is preferred over creating a duplicate. The screens below use the same canonical UI package as the operational product with a synthetic public adapter; real household finance values and the operational backend remain private.
Highlights
- Family Budget journey from mobile quick entry to ledger, purpose accounts, assets, and month-end decision
- Separate joint and individual ownership plus plan and actual so both household members can review the same month from different views
- Protect financial writes through existing-actual-first linking, confirmation, read-back, partial-success disclosure, and reopen
Tech Decisions
- ▶Separate recurring rules, monthly occurrences, and the actual ledger; the model is larger, but plan changes cannot overwrite recorded facts.
- ▶Choose user confirmation over automatic candidate linking; it adds a step but prevents incorrect joins in a financial ledger.
- ▶Keep the public UI package and synthetic demo as secondary evidence, reproducing UI contracts and public boundaries without exposing operational implementation.