A Personal Finance App (Unreleased)

Overview

Most money apps are very good at telling you where your money went and almost useless at telling you what to do next. I wanted the opposite. I wanted to open an app and see how much cash is actually free after everything already spoken for, what I need to put aside each month to hit a goal on time, when a debt is actually paid off under a given budget, and what my next tax payment is going to be.

Nothing I tried did all of that in one place, so I built it. It started as a tool for my own situation, sized to exactly the problems I had. It has since grown past that, and I am now building it out into something other people can use.

I am keeping the name and the repository private until it is closer to ready.

What it does

• Ledger. Every account and transaction in one normalized shape, whether it was synced from a bank, imported from a file, or typed in by hand. Manual entry is a first-class path, not a fallback. The app is fully usable without connecting anything.
• Buckets. Virtual envelopes layered over real balances. You reserve cash for the trip, the new roof, the quarterly tax bill, and the dashboard shows what is genuinely free after those reservations. Buckets never move real money.
• Goals. A target amount, optionally with a date, and the required monthly contribution derived from both.
• Bills. Recurring obligations that reconcile themselves against imported transactions after each sync, suggesting matches rather than applying them silently.
• Debt engine. Each liability modeled with its own interest and payment behavior, then solved. Give it a monthly budget and it returns the payoff date. Give it a deadline and it returns the budget. Other modes minimize total interest, protect cash flow, or preserve savings.
• Forecasting. Deterministic daily and monthly projections of cash, debt, goals, and taxes, where you can click any point and see the events that produced it.
• Scenarios. Named sets of overrides on income, bills, debt, or goals, compared side by side without touching the baseline data.
• Tax planning. Self-employment tax estimates with quarterly payment targets, deduction review, and an export an accountant can actually read.

How it is built

Next.js and TypeScript on the front, PostgreSQL and a typed ORM behind it. Tests run against a real embedded Postgres rather than mocks, so migrations and queries are exercised for real, and the numeric engines are covered by property tests and golden cases in addition to ordinary unit tests. Design decisions are recorded as ADRs, because six months from now I will not remember why a rule works the way it does.

Two rules shaped almost everything else:

It reads and plans. It never moves money. No transfers, no bill pay, no trading. That single constraint removes an entire category of catastrophic bug and an entire category of regulatory burden, and it costs nothing, because the hard part was never moving the money. It was knowing what to do.

No language model touches a calculation. Every number in the app comes from deterministic code with versioned rules and inspectable inputs. A model that is confidently wrong about your tax liability is worse than no app at all. Where a required fact is missing, the engine says so and returns a bounded answer instead of inventing the gap.

Where it goes next

The version I have is a single household app. Turning it into a product means multi-tenancy done properly, onboarding that works for someone who did not build it, broader institution coverage for sync, and tax rules that generalize past the one situation I built against. That last one is the real work: the engine is already structured around versioned, source-backed rules, but every jurisdiction added is a new set of sources to verify and keep verified.

That is what I am working on now.