Should I vibe code
Personal finance app for spending, budgets, investments, and net worth
Your bank feed is read-only. Your database isn't — it's a map of everywhere you go and everyone you pay.
?
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
The chart is not the product. Copilot's real work is the boring half: reconnecting the credit union that quietly stopped syncing, matching a pending transaction against the posted one that arrives three days later under a different description, and keeping categorisation that does not need retraining every month. Your version will do all of that beautifully for about a week. What it will also do, from the first commit, is hold a long-lived aggregator token for every account you own next to a line-by-line ledger of your life, on a box you configured one Sunday and have not thought about since.
What actually breaks
not "if". the specific failures.
- A bank connection dies quietly. The aggregator returns ITEM_LOGIN_REQUIRED, your code only checks for HTTP 200, and the app keeps rendering last month's balance as though it were this morning's
- Pending transactions posting days later with a different amount and a different description, so every reconciliation is a fuzzy match somebody has to write
- Categorisation rules that were right in January and silently wrong by June, moving spending between budgets without ever raising an error
- The access tokens themselves: long-lived, broadly scoped, and sitting in the same database as the data they unlock, with whatever encryption the agent happened to pick
- Two years of hand-corrected categories, gone with the container volume you had forgotten was the only copy
You make an offer on a flat because the net-worth figure said you could. The figure was wrong by eleven thousand dollars, because the brokerage connection stopped refreshing in March and your app has no concept of staleness — it renders whatever the last successful sync wrote, undated, in the same confident typeface as everything else. You find out on a Tuesday from an actual statement, and you spend the evening reading your own sync code trying to work out how many of the last five months were fiction.
Is that you?
the verdict is a default, not a law
- It runs on your machine, against statement files you export yourself
- It is read-only analysis over a CSV, with no stored tokens and no scheduled job
- You want a categorisation view your bank refuses to give you, and you are content to re-import by hand each month
- It is deployed anywhere behind a login you wrote
- Aggregator access tokens live in the same store as the transactions they unlock
- Anyone else's accounts are in it — the household version doubles the sensitivity and ends your right to say 'my risk, my problem'
- You would act on a number in it without opening the underlying account first
If you build it anyway
the checklist, then the prompt that enforces it
- Start with file import. OFX and CSV give you the entire product minus the token, and sync can come later once you know the thing is worth keeping.
- If you do use an aggregator, keep access tokens in a separate store with its own key, not in a column beside the transactions.
- Every account renders its own last-successful-sync timestamp next to its balance. An undated number is a lie your UI tells with total confidence.
- Treat sync failures as first-class UI, never as logs. A dead connection has to be impossible to miss inside the app itself.
- Make the transaction store append-only with corrections in a separate table, so a bad import is replayed rather than repaired by hand.
- Encrypted export on a schedule, and restore from it once for real. Two years of tuned categories is the only thing here you cannot re-derive from the bank.
I am building a personal finance aggregator for my own accounts. Apply these constraints before any features, and push back if I ask you to drop one.
1. Build CSV/OFX import first and get the whole application working on it. Do
not add a bank aggregator until I explicitly ask, and when I do, tell me
what changes about the threat model before writing any code.
2. Never handle bank usernames or passwords. If I propose scraping a bank site
with my own credentials, refuse and explain why.
3. Aggregator access tokens live in their own encrypted store, keyed from an
environment variable, in a different table from transactions. Never log a
token, and never let one reach an error message or a stack trace.
4. Implement encrypted export and a tested restore path before any import
path. I must be able to get two years of corrected categories out before I
am allowed to put anything in.
5. Every account record stores lastSuccessfulSyncAt, and every balance in the
UI renders that timestamp beside it. A number with no date is the failure
mode I care about most.
6. Sync errors, ITEM_LOGIN_REQUIRED above all, surface as a visible banner on
the account. A silently dead connection must be impossible to miss.
7. The transactions table is append-only. Categorisation and corrections go in
a separate table keyed to the transaction id.
8. Deduplicate pending against posted explicitly. Write the matching rule in
the README and show me the unmatched pile rather than guessing at it.
9. Nothing in this application writes to a financial institution. No
transfers, no bill pay, no card controls. Refuse if I ask.
10. If I ask to deploy this publicly, or to add accounts belonging to someone
else, stop and tell me the blast radius has changed and that I now need
real auth rather than the session handling you would otherwise generate.
11. Out of scope, and say so instead of faking it: performance attribution,
tax lots, multi-currency, and anything resembling advice.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
The moment you want sync rather than import. Thirteen dollars a month buys four aggregator relationships, somebody else's on-call rota for the Tuesday a bank changes its login flow, and categorisation that improves without you retraining it. Actual Budget is the honest free middle: somebody else's code on your own server, and no token storage schema you invented at midnight.
$13/mo is cheaper than your weekend.
Keep the ledger in something you can open without your app — plain SQLite with documented columns, plus a monthly CSV dump somewhere off the box. If you move to Copilot, Monarch or Actual, the thing you need to carry is the categorisation history, not the balances: balances re-derive from the bank in a minute, and the categories took you two years.
Local-first open-source envelope budgeting; the sane middle if you want to own the data without owning the sync code.
Questions
Aggregator access is read-only. Isn't most of the risk gone?
It removes the worst case — nobody moves money with a read token — and it removes none of the disclosure. A read-only ledger still says where you live, who pays you, which pharmacy you use and which lawyer you paid in March. 'Read-only' describes what the token can do, not how long it lives or how casually it got stored.
What actually goes wrong first?
A connection stops refreshing and nothing tells you. Aggregator links break constantly — a bank changes an MFA flow, a credit union rotates something — and the failure arrives as a status field rather than an exception. Code that only checks for HTTP 200 renders the last successful sync forever, undated, looking completely healthy.
Is the local-only version fine?
Largely, and it is the version worth building. Import statement files by hand, keep the database on your laptop, and you have a single-user read-only tool whose worst case is a wasted weekend. Everything else on this page is about what changes the day you add a hostname and a login.
Why isn't regulatory exposure scored higher for something this financial?
Because a tool you run on your own accounts is not a financial institution, and data protection law carves out purely personal and household processing. What does bite is contractual — every aggregator's developer agreement carries data handling terms — plus ordinary security-of-processing duty the moment someone else's accounts are in there. Real, but not PCI, and inflating it would make the rest of this page less believable.
- FTC Safeguards Rule — what your business needs to know
- GDPR Art. 32 — security of processing (EU)
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.
The bug is not a stack trace. It is a plausible number, beautifully formatted, in a board pack you already presented.
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.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice