← Product

Case study 02 · Concept · Product design · AI direction

MoneyLedger

one HTML file · zero dependencies · AES-GCM encrypted · fully offline

A private, offline personal-finance ledger that lives in a single HTML file — open it in a browser and it just runs. No cloud, no account, no network. I run my own money on it.

Personal finance tools force a bad trade: convenient but cloud-hosted, or private but a clunky spreadsheet. I wanted the third thing nobody makes — private, offline, own-your-data, and actually designed.

My role
Concept, product design, UX, functionality, branding, AI direction — the whole thing.
Built with
Claude — authored, not just used. I set the product's principles and directed the build against them.
Status
In daily use on my real finances since July 2026 — 1,595 transactions.
The decision it turns on

Never write after a failed read. Bad state triggers snapshot recovery, or the app refuses all writes to preserve the corrupt record rather than overwrite it. For a finance app, silent data loss is unforgivable — so I designed the persistence layer around protecting the record, not around the happy path. That's a product-judgment call, not a code trick: decide what the product can never do to the user, then build backward from it.

MoneyLedger dashboard: five KPI cards for net worth, debt, income, expenses and net for the month, a recent-activity list, a spending donut broken out by category with each slice's amount in the legend, a debts panel and a six-month income-versus-expenses chart.
The dashboard. Eleven themes exist because a tool you open several times a week shouldn't feel like a tax form — that's a retention decision, not decoration.
The app's data-check dialog reporting one issue: a credit card holding a positive balance of $500.00, warning that net worth is overstated by $1,000.00 until the opening balance is entered as owed, and noting that if the card was genuinely overpaid the figure is correct.
The integrity check, turned on its author. You just wait a minute, mister. It names the exact overstatement — $1,000.00, twice the balance — and concedes the case where the user is right. A product that states the consequence and admits its own uncertainty is exercising judgment, not running validation.

The app also carries an encrypted password vault — logins with live TOTP codes, cards, secure notes, its own passphrase. The design decision worth naming is section-lock rather than app-lock: the vault is a locked room inside an app you are already using, so checking a balance never asks for a passphrase and reading a password always does. ★ And it is the cleanest evidence here for why a person still has to look. Automated verification proved the cryptography correct and found zero behavioral defects — every bug in that build came from driving a real browser. The maths was right and the product was broken. The bug ledger →

When a self-imposed constraint — no third-party JavaScript, no network — left no room for a spreadsheet library, I had the AI hand-build the Excel engine: a ZIP/CRC32 reader-writer. The constraint forced a cleaner, fully self-contained result. That's the pattern I care about: the limit is the design tool.

See the full evidence pack →

All five product case studies →

The design-side case study → — the mark across three rounds, eleven themes at verified parity, and one theme decided in two framings.