YNAB

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a budgeting tool that replaces YNAB — and know exactly what makes this ALMOST.

Two things, and the second is the larger. **Bank connections** need a data provider, which in most countries is a contract rather than an API key. And **the method is taught** — the product is a way of thinking about money with software attached, and the software without the method is a spreadsheet. Build the method faithfully or do not build it.

STACK
- Node 20+ with Fastify, server-rendered HTML with a little vanilla JS
- SQLite through better-sqlite3, WAL mode
- A PWA for the phone, because entering a transaction happens at a till
- Caddy in front

THE METHOD, WHICH IS THE PRODUCT
- **Every unit of money you have is assigned a job before it is spent.** Not a forecast of a month, not a limit per category — an allocation of money that actually exists
- So the top number is 'money to assign', and it starts at your real balance. Assigning reduces it; it can never go below zero
- Overspending in a category is covered by moving money from another, deliberately, and the interface makes that the obvious action rather than an error message. That single behaviour is the whole method: you are not tracking a plan, you are deciding again
- Next month is funded only from money you have now. No projected income, ever
- If you soften any of that, you have built a spending tracker, and there are plenty of those

THE DATA MODEL
- accounts: id, name, kind, is_on_budget, currency, closed_at — a credit card is on budget and behaves differently from a savings account
- categories: id, group_id, name, position, is_hidden; category_groups
- transactions: id, account_id, date, payee_id, category_id, amount_cents, memo, cleared, approved, transfer_transaction_id, import_id, created_at
- subtransactions: id, transaction_id, category_id, amount_cents, memo — a split, which is common and must not be an afterthought
- allocations: id, month, category_id, amount_cents — the assignment per category per month, and the heart of it
- payees, and payee_rules for automatic categorisation
- scheduled_transactions with a recurrence
- Amounts in integer cents. Never a float. Balances derived from transactions at query time, never stored, or they will eventually disagree with their own rows

CREDIT CARDS, WHICH IS WHERE THESE TOOLS GET IT WRONG
- Spending on a credit card in a budgeted category moves that money into a payment category for the card
- So the amount available to pay the card is always the amount you have already budgeted for what you bought. That is the mechanism that turns a credit card from a debt spiral into a payment instrument, and it must be automatic
- Interest and fees are their own transactions, and carrying a balance is shown honestly rather than hidden

GETTING TRANSACTIONS IN
- Manual entry that takes three seconds on a phone: amount, payee, category. That path must be excellent, because it is the one that works everywhere
- Import from a bank export — CSV, OFX, QIF — with a mapping step, a dry run, and duplicate detection by a stable import id, then by date, amount and payee. A double-imported month is the classic disaster
- A bank connection through a provider if you can get one, incremental with a cursor, and every imported transaction unapproved until a person confirms it. Never let an import silently create budget movements
- Payee rules learned from what you chose last time, applied as a suggestion

RECONCILIATION
- Mark transactions cleared, enter the bank's balance, and the difference is shown. If it does not match, something is wrong and the tool says so
- A reconciliation locks the transactions up to that point
- Without reconciliation the numbers drift and the whole thing quietly stops being true

WHAT IT SHOWS
- The month: assigned, activity and available per category, with the available column being the only number that matters
- Age of money: how long between receiving a unit and spending it. That is the single best measure of whether the method is working
- Net worth over time, and spending by category with a comparison
- All computed from rows

PRIVACY AND ESCAPE
- This is a complete record of your financial life. Encrypt at rest, authenticate properly, expose nothing you do not need, and never send it anywhere
- Export everything as CSV and JSON in one command
- No analytics. Not one event

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, ENCRYPTION_KEY, provider credentials
- Migrations on boot, each once; nightly backup off the machine, encrypted, with a tested restore
- Health endpoint

WHAT MATTERS MOST
Money-to-assign never going negative, and the credit card mechanism. Those two are the method. Build them exactly, live with it for two months, and only then decide whether you miss the bank connection.