Should I vibe code
Import transactions and maintain a transparent personal ledger with rules and reports
No bank token, nothing to steal. Just a CSV parser you will maintain for the rest of your life.
?
Their verdict, the Monthly subscription price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Take the bank connection out of a personal finance app and most of what makes Copilot and Monarch dangerous leaves with it: no long-lived aggregator token, no second person’s chequing account, nothing worth stealing that you do not already have on your own laptop. What remains is buildable and is, honestly, a maintenance story. Lunch Money’s substance is the unglamorous middle — an import that recognises the transaction it already has when you upload an overlapping CSV, rules that keep working after your supermarket adds a store number to its merchant string, multi-currency that uses the rate from the day of the transaction rather than today’s, and four years of hand-corrected categories that exist in no other system. You will have the ledger by Sunday evening. You will be maintaining CSV parsers for as long as you use it.
What actually breaks
not "if". the specific failures.
- Duplicate detection on re-import. Banks reissue the same row with a new id, an amended date and a reworded description, and "skip if identical" is not a dedupe strategy
- The CSV itself: every bank exports a different shape, changes it without telling anyone, and picks the date format that ruins one month in twelve
- Rules, quietly. The rule that caught your supermarket stops matching when the merchant string gains a store number, and the spending moves to Uncategorised without an error anywhere
- Multi-currency. Convert at today’s rate instead of the rate on the transaction date and last year’s report changes every time you open it
- Recurring-expense detection, which demos beautifully on twelve tidy months and falls apart the first time a subscription changes price or bills on the 29th
- The categorisation history — the only genuinely irreplaceable thing in the app — sitting in a SQLite file on a laptop that has never been backed up
Is that you?
the verdict is a default, not a law
- It runs locally, against statement files you export yourself
- You are the only person in it and always will be
- You want a view your bank refuses to give you, and re-importing by hand once a month is a fair price
- You are about to add Plaid, because that is a different application with a different verdict — see the Copilot Money entry
- Someone else’s accounts go in. A partner’s ledger ends the "my risk, my problem" argument immediately
- It would live on the public internet behind a login your agent generated on a Sunday
- You would act on a number in it without opening the actual bank first
If you build it anyway
the checklist, then the prompt that enforces it
- Import is idempotent or it is broken. Hash account, date, amount, description and any bank-supplied id into a deterministic key, and surface near-collisions for review instead of silently dropping them.
- Keep the raw import file, and make every parsed row point back to the file and line it came from. A bad parser is then replayed rather than repaired by hand.
- Transactions are append-only; categorisation and corrections live in their own table keyed to the transaction id.
- Store the exchange rate you used with the transaction, not just the currency. Historical reports must not move when the market does.
- Rules need a dry run with a match count and an "unmatched this month" view. A rule that quietly stops matching is the silent failure mode of this entire category.
- Backup before features: an encrypted dump off the machine, and one restore you have actually performed. Everything else re-derives from the bank; the categories do not.
I am building a single-user personal finance ledger that imports statement files. No bank aggregator. Hold me to that, and to the following.
1. Do not add Plaid, Yodlee, SimpleFIN or any aggregator. If I ask, stop and
explain what changes about the threat model — long-lived tokens beside the
data they unlock — before writing a line of it.
2. Never handle bank usernames or passwords, and refuse if I suggest scraping
a bank site with my own credentials.
3. Build export and a tested restore before any import path. I must be able
to get four years of corrected categories out before I am allowed to put
anything in.
4. Import must be idempotent. Compute a deterministic key from account, date,
amount, normalised description and any bank id; re-importing an
overlapping file must change nothing and must show me the near-matches it
was unsure about rather than guessing.
5. Keep every raw import file, and store the source file and line number on
each transaction so a parser bug can be replayed.
6. Transactions are append-only. Categories, notes and splits go in a
separate table keyed to the transaction id.
7. Store the FX rate used with each foreign transaction, dated. Never
convert historical amounts at the current rate.
8. Rules run as a dry run first, reporting how many transactions each one
matched, and the app has a permanent view of what matched nothing this
month. A rule that silently stops matching is the bug I care about most.
9. Keep it local by default: no hosting, no login, no multi-user. If I ask to
deploy it or to add my partner’s accounts, tell me the blast radius has
changed and that real authentication is now the first requirement.
10. Out of scope, and say so instead of faking it: investment performance,
tax lots, bill pay, and anything that moves money. If I want sync rather
than import, tell me to look at Lunch Money or Actual Budget instead.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
You want the import pipeline to be somebody else’s problem. Ten dollars a month — or pay-what-you-want annually from $60 — buys parsers that have met several hundred banks’ CSV quirks, multi-currency with historical rates, and an open API that lets you keep tinkering without owning the boring half. Actual Budget is the free middle: local-first, open source, and someone else’s import code.
$10/mo is cheaper than your weekend.
Keep the ledger in plain SQLite with documented columns and dump a monthly CSV of date, account, amount, currency, description, category and notes somewhere off the machine. That file is the asset: Lunch Money, Actual Budget and Firefly III all import a flat CSV, and the balances re-derive from the bank in minutes. Store the category as text rather than an internal id and the export still means something after you delete the app.
Local-first open-source envelope budgeting with a working import path and no hosted dependency.
Self-hosted personal finance manager with rules, multi-currency and a documented import tool.
Questions
Why is this softer than the Copilot Money and Monarch entries?
Because the aggregator is the thing being scored there. A Plaid connection means a long-lived, broadly scoped token sitting next to the ledger it unlocks, and Monarch adds a second adult’s accounts on top. Strip both out and you are left with a single-user application over files you already downloaded, which is a completely different risk profile with the same charts.
What actually goes wrong first?
The second import of an overlapping file. Most people build "insert every row" first, notice the duplicates, then bolt on a rule that skips exact matches — which fails the moment a bank amends a pending transaction. You end up hand-deleting rows in a database, which is exactly the position the ledger was supposed to save you from.
If I add bank sync later, does the verdict change?
Yes, to your-funeral, and the reasoning is on the Copilot Money page rather than this one. The line is not "does it have my transactions" but "does it hold a credential that can fetch more of them without me".
Is the rules engine worth building?
It is the most satisfying part and the part that rots. Rules are cheap to write and impossible to notice failing, so whatever else you skip, build the report that tells you what stopped matching this month.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Tracking your portfolio is fine. The moment it says “you should”, you have built advice.
Your own budget, your own rules, your own bug that told you you had money.
Your bank feed is read-only. Your database isn't — it's a map of everywhere you go and everyone you pay.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice