Should I vibe code
Import transactions, categorize them, and forecast cash flow on a calendar
A ledger can be checked against a statement. A ten-year forecast can be checked against nothing until it’s too late.
?
Their verdict, the Foundation 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
Three finance entries on this site already argue about bank tokens and household data, and all of that is true here too — read Copilot Money for the token story and Monarch for what a second person changes. PocketSmith's own thing is the forecast: repeating events projected onto a calendar ten, thirty or sixty years out, which is literally what its tiers are priced on. That is a different kind of risk, and a quieter one. A ledger can be checked against a statement; a projection can be checked against nothing at all until the date arrives. The engine underneath it is recurrence rules, month-end arithmetic, currency at the rate of the day, and a rule about what happens when a scheduled transaction and the real one both show up — and every one of those is wrong in a way that renders as a perfectly smooth line. You will have a beautiful forecast by Sunday. You will not have a forecast you should make a decision on, and the gap between those two is the entire product.
What actually breaks
not "if". the specific failures.
- Recurrence rules. 'The last business day of the month', 'every second Friday', 'the 31st in February' — four date libraries, four answers, and the disagreement only shows up in year three of the projection
- Scheduled events that project forever, including the subscription you cancelled in March and the contract that ended last year
- Double counting, where the scheduled transaction and the real one that actually arrived both land in the same forecast bucket
- A bank feed dying quietly, so the projection starts from an opening balance that stopped moving three weeks ago and says nothing about it
- Currency conversion applied at today's rate to a transaction from 2023, which is fine until a third of your spend is in another currency
- Rounding and compounding choices made in one line at midnight, quietly amplified across a sixty-year horizon
- Aggregator access tokens sitting in the same database as the ledger they unlock, with whatever encryption the agent happened to reach for
Is that you?
the verdict is a default, not a law
- It runs on your own machine, over statement files you export yourself, with no stored tokens and no scheduled job
- The forecast is a sanity check on decisions you would make anyway, not the thing that makes them
- You will actually read the assumptions panel, because you are the one who wrote it
- You are prepared to reconcile the projection against a real statement every month for the first six months
- You would sign something on the strength of a number your own code produced and nobody has ever reconciled
- Aggregator tokens live in the same store as the transactions they unlock
- Somebody else's accounts are in it, at which point read the Monarch entry — the blast radius stopped being yours
- The forecast renders as a chart with no way to open a projected month and see which rules produced it
If you build it anyway
the checklist, then the prompt that enforces it
- Start with file import. OFX and CSV give you the entire application minus the token, and you can decide later whether sync is worth the threat model.
- Make every projected balance explainable: click a month, see the exact list of scheduled events, rules and opening balance that produced it. A forecast you cannot open is a rumour with axes.
- Give scheduled events a mandatory end date or an explicit 'until I stop it', and put a review prompt on anything that has been running for a year.
- Reconcile forwards. Every month, diff last month's projection against what actually happened and show the error, in the app. A forecast with no track record is a guess in a nice typeface.
- Use one dated FX rate per transaction, stored at import, and never re-derive historical amounts from today's rate.
- Render lastSuccessfulSyncAt beside every balance. An undated number is the most confident lie your UI can tell.
- Make the transaction store append-only, with categorisation and corrections in a separate table, so a bad import is replayed rather than hand-repaired.
- Pick one date library, pin it, and write explicit tests for month-end, leap years, and 'every second Friday' across a DST boundary.
I am building a personal cash-flow forecaster for my own accounts: a transaction
ledger plus repeating events projected onto a calendar years out. The dangerous
output is a confident wrong number, not a leak. Apply these and push back if I ask
you to drop one.
1. Build CSV/OFX import first and get everything working on files. Do not add a bank
aggregator until I ask, and explain the threat model change before you do.
2. Never handle bank usernames or passwords. If I propose scraping a bank site with
my credentials, refuse and explain why.
3. Implement encrypted export and a tested restore before any import path exists.
Years of hand-corrected categories are the only irreplaceable data here.
4. Every projected figure must be explainable: a view showing opening balance, the
scheduled events applied and the rules that fired. Build it before any chart.
5. Pin one date library and write explicit tests for month-end rollover, leap years,
'last business day' and fortnightly schedules crossing DST. Failures first.
6. Every recurring event requires an end date or an explicit indefinite flag. Never
default to projecting something forever.
7. Deduplicate a scheduled event against the real transaction that matches it, in
one documented place, and show me the unmatched pile rather than guessing.
8. Store an FX rate per transaction at the transaction's own date. Never convert
historical amounts using today's rate.
9. Every account stores lastSuccessfulSyncAt and every balance renders it. A number
with no date is the failure mode I care about most.
10. Add a backtest: each month, compare last month's projection to what actually
happened and display the error inside the app.
11. Nothing in this application writes to a financial institution. No transfers, no
bill pay. Refuse if I ask.
12. If I ask to deploy this publicly or add someone else's accounts, stop and tell
me I now need real auth rather than the session handling you would generate.
13. Out of scope, and say so instead of faking it: tax lots, performance
attribution, 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
As soon as you want the forecast to be load-bearing. Fifteen dollars a month buys an engine whose edge cases were found by other people's mortgages rather than yours, plus bank feeds and somebody else's on-call rota for the Tuesday a bank changes its login flow. If it is really only the ledger you want, Actual Budget is the honest free middle — someone else's code on your own machine, and no token-storage schema you invented at midnight.
$14.95/mo is cheaper than your weekend.
Keep the ledger in something openable without your app — SQLite with documented columns, plus a monthly CSV dump somewhere off the box. Export scheduled events and rules separately and in a readable form, because that is the part no other tool will reconstruct for you: balances re-derive from the bank in a minute, categories took you two years, and the recurrence rules took you a fortnight of fiddling. PocketSmith, Actual and Firefly III will all take the transactions; none of them will take your forecast model, so write it down as text somewhere.
Local-first open-source envelope budgeting; the sane base if you want to own the data without owning the sync code.
Self-hosted double-entry personal finance manager with bills and recurring transactions — the closest open-source thing to a forecast engine.
Questions
Why is this DEMO ONLY when Copilot Money is YOUR FUNERAL?
Because the blast radius is different. Copilot's entry is about holding aggregator tokens and a line-by-line map of your life; that is real and it applies here too. But PocketSmith's distinctive feature — the forecast — fails inward. A wrong projection costs you a decision, not a disclosure notice, and 'it can only waste your own money' is squarely the DEMO ONLY shape. Add a second person's accounts and you should read the Monarch entry instead.
What actually goes wrong first?
A scheduled event you forgot to end. The gym membership you cancelled in March is still in the projection, so every month from here to 2036 is off by forty dollars, compounding against everything else you layered on top. Nothing errors. The chart is smooth. You find out the day the number matters.
Is the local, CSV-only version fine?
Largely, yes, and it is the version worth building. Import statement files by hand, keep the database on your laptop, skip the tokens entirely, and the worst case is a wasted weekend plus a forecast you learn not to trust. Everything sharper on this page starts the day you add a hostname, a login, or a bank connection.
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.
Your bank feed is read-only. Your database isn't — it's a map of everywhere you go and everyone you pay.
No bank token, nothing to steal. Just a CSV parser you will maintain for the rest of your life.
Add a second person and "my risk, my problem" stops being true. You are now someone else's bank-data custodian.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice