Personal Finance OS

After being laid off, the core problem was simple: see all money across multiple accounts, understand monthly burn rate, calculate how long severance would last, and make informed decisions about spending and the job search. Traditional spreadsheets are tedious to maintain and don't make it easy to see the big picture. Existing tools like Mint or Personal Capital were overkill and didn't answer the core question directly; nothing felt like it actually answered "how long can I sustain this?"

A personal project solving a personal problem, with no external deadline, built sustainably. It doubles as an opportunity to showcase UI, data visualization, and backend skills together — and because it uses real data, it becomes a real case study. Personal finance data also demands real thoughtfulness around security and privacy.

• Create a single source of truth for financial position
• Answer five core questions: Where is my money? Where is my money going? How much do I owe? How long can I sustain this? What should I do next?
• Enable scenario modeling (e.g. "what if I get a job in October?")
• Show the ability to build UX, data visualization, and backend together

• Personal project — lower priority than consulting leads
• MVP needed to be achievable in 2-3 weeks
• Needed to actually be used, so it had to be genuinely good
• Security and privacy matter given how sensitive financial data is
• Simple enough to maintain long-term

Years of personally handling finances meant already knowing what matters, what existing tools do well or poorly, and where the gaps in the market are — enabling something uniquely tailored to this specific situation rather than a generic budgeting app.

Core philosophy: a financial ledger and calculation engine first, not a UI-first design. Accounts, transactions, categories, and rules feed a financial model (the ledger engine) that powers calculations for cash flow, debt, runway, and net worth, which in turn drive the dashboard, forecast, scenarios, and alerts. Tech stack: Next.js + TypeScript for frontend and API routes, Supabase + PostgreSQL for the relational database, Recharts for data visualization, and Vercel for hosting. Supabase was chosen over Firebase because financial data is inherently relational (accounts, transactions, and debt are all interconnected) and the app needs complex queries — like spending by category over time — that PostgreSQL handles better.

Clarity over decoration — this is a tool, not art. Key screens: a dashboard for financial position at a glance, an accounts view for money in and out, a transactions view for where money actually went, a debt view showing what's owed and payoff scenarios, and a forecast view projecting runway. Design decisions: dark mode by default (a lot of time is spent in this tool, and dark is easier on the eyes), keyboard-friendly for power-user speed, mobile-responsive but optimized for desktop, and color-coded categories for quick scanning.

MVP scope targeted 2-3 weeks. Week one: repo and Supabase setup, the accounts/transactions/categories/rules data model, a dashboard showing net worth, cash, debt, and runway, account add/edit, and transaction entry or CSV import. Week two: rule-based and manual categorization, an avalanche/snowball debt payoff calculator, a 30/60/90-day and 6/12-month forecast, and polish and testing. Explicitly not in MVP: bank sync (Plaid), a "what if" scenario engine, advanced reports, a budgeting module, and net worth history/trends.

• Data quality — getting historical financial data into the system accurately
• Security — financial data requires real thoughtfulness around encryption and access control
• Accuracy — this is real money, so the calculations have to be correct
• Scope creep — financial features are effectively infinite, so MVP discipline matters
• Usefulness — the tool needs to actually guide decisions, not just display data

The tool is intended to provide clear visibility into financial runway, understanding of spending patterns, debt payoff scenarios, and data-driven decisions about job search and spending. (Actual outcome metrics — accuracy of runway predictions versus reality, time saved versus spreadsheets, decisions made based on insights — are TBD until the tool has been in use for a while.)

• (Lessons learned are TBD — to be filled in once the tool has been in real use for a while: what building financial software taught, any surprises in the underlying financial picture, which design decisions worked or didn't, and what would be done differently.)