Family Finance OS

Why it exists

For years, I managed household finances in a spreadsheet alongside a paid Monarch subscription. I collected and reconciled balances from banks and cards, then decided where to send cash and when. The decisions were usually obvious once I had the numbers.

My first attempt was a budgeting app organized around entering pay cycles by hand. I abandoned it because it automated the typing but left the collecting manual. I kept it as a schema reference and started over.

Before writing code, I set the principle "Automate the work, not the understanding." Dashboards and cash-flow views help me understand what's happening. I decided the app would never move money: it recommends payments, links to the bank's own bill-pay page, and logs my confirmations. It replaced Monarch and the spreadsheet.

What it does

Balances and transactions sync automatically through a read-only aggregator. I maintain unsupported accounts manually. The app stores pay schedules and bill due dates, then projects incoming and outgoing cash per account to show the day with the least cash. The combined balance can be positive while an individual account is about to overdraft.

It detects recurring bills and matches payments as they post, marking bills paid, due, or missing. I confirm or dismiss its suggestions.

On payday, the app recommends allocations in order, with the inputs and reasoning behind each. A pure, tested function calculates card and loan payments in avalanche order, highest interest rate first, to pay off the debt faster. A language model explains recommendations and flags concerns. It never decides a dollar amount.

I use category budgets with monthly pacing, categorized transactions, and a view of monthly interest costs. The goal view projects a debt-free date from current behavior and lets me compare scenarios before choosing a plan.

How it's built

Claude Code built the app. Codex reviews it. I'm the product manager and the only user who files bugs.

It's an installable, mobile-first web app: Next.js on Vercel, TypeScript, Drizzle, Supabase for Postgres and auth, Tailwind, and shadcn/ui. The two people in the household each sign in with Google. Row-level security restricts every table to the household.

The app runs a nightly sync, a daily briefing, and a payday allocation flow. SimpleFIN, the read-only aggregator, lags banks by up to a day. Expired credentials silently cause partial syncs. The app displays both conditions, and I reauthorize at the aggregator when credentials expire.

I track when each account last synced and when the bank reports the balance was accurate. The app stores both and never overwrites the bank's timestamp with its own.

Before every production change, I run lint, typecheck, unit tests, and browser end-to-end specs, then two adversarial reviewers examine the diff. When changes affect financial behavior in real use, I run deeper audits across subsystems.

What building it taught me

A paycheck-detection fix passed its unit test and changed nothing in production. I'd used real data, but the test included two extra paydays outside the live query window. I added that window as a regression test and now run the real thing before calling a fix successful.

A JavaScript Date shifted the day-of-month across a timezone boundary and silently broke a plan. The app now stores and emits dates as text in the household's timezone.

In eleven consecutive reviews, reviewers found a critical defect inside the previous fix: it recreated the bug class it existed to remove. I keep the review step for that reason. When a field changes meaning, I test the composed pipeline and check whether it's a label or a key.

I also prefer inferring from the transaction feed with a confirm-or-dismiss step over asking me to configure bills. The data is already there.

Status

The app is live in my household, where I've used it daily since early 2026. It holds real accounts, so I do not link it here and never will. I plan screenshots from a seeded demo household to show the interface without any real figure.