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 (backend and operational automation belong to the private operating product)
2026-07-07 — present
A household budget connecting daily entries, joint and individual ownership, purpose accounts, and recurring plans to month-end review. The public demo exercises existing-record linking, realization, reopen, and month-end warnings with synthetic browser-local data.
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
Private operating-product 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 existing records · separate monthly state
The public synthetic demo preserves ledger records after reopen
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.
Private operational automation previews requests for approval, reads back the ledger and dashboard, and distinguishes partial success from verification failure. The public demo evidences browser-local reconciliation, not this server or automation path.
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
Evidence links support individual claims. Source and test coverage are distinct from owner-recorded operating observations.
26 canonical UI files
How are the UI source of truth and allowed seams pinned?
Local reconciliation, ledger preservation, and month-end warnings
Where are salary and savings links, expense realization, ledger-preserving reopen, insufficient purpose-balance warnings, and reset implemented and regression-tested?
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
- Exercise existing salary and savings links, expense realization, ledger-preserving reopen, and insufficient purpose-balance warnings in the synthetic demo
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.