Should I vibe code
Personal finance dashboard for budgeting, transactions, goals, and net worth
Add a second person and "my risk, my problem" stops being true. You are now someone else's bank-data custodian.
?
Their verdict, the Core 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
Everything true of a solo budgeting app is true here, and then there is a second person. Monarch's shape is a household: two logins, joint accounts linked from both sides, shared category edits, and one ledger documenting both of your lives. Build it yourself and you have not written a spreadsheet, you have stood up a small multi-tenant service holding long-lived aggregator tokens for somebody else's chequing account behind session handling your agent generated on a Sunday. The charts will be lovely. The parts that decide whether this is fine — invite revocation, per-member scoping on every query, what happens when one of you leaves — are the parts nobody builds until the day they are needed.
What actually breaks
not "if". the specific failures.
- The invite. A household join link is a bearer token for two people's complete financial history, and the generated version is a sequential id in a URL with no expiry, living in a message thread forever
- Scoping. Every query needs a household filter and a member filter, and the one that gets forgotten is the nightly digest job, which selects by household and mails everything to everyone who was ever a member
- Joint accounts linked by both of you, arriving as two accounts. Net worth is now overstated by an entire balance and nothing in the UI hints at why
- Revocation. Removing a person is one line in the users table and much harder everywhere else: their sessions, their aggregator items, the exports they scheduled, the token sitting in their phone
- Connections only their owner can repair. Your partner's credit union stops refreshing, the banner renders on your dashboard rather than theirs, and you both plan around a number frozen in March
- Category edits racing each other. Two people recategorising the same transaction, last write wins, and a budget quietly moves
The relationship ends amicably and she asks to be taken off the app. You kill her session, flip her member row to inactive, and consider it handled. Six weeks later she forwards you the Sunday digest: full cash-flow summary, category breakdown, every account including the one she is no longer supposed to see. The digest job never learned about members — it selects transactions by household_id, joins the recipients table, and has been running happily since February. You wrote it in an afternoon and it is the most reliable component in the system.
Is that you?
the verdict is a default, not a law
- It is one person, one machine, and no login screen at all
- It reads statement files you export by hand instead of holding aggregator tokens
- The other member of the household receives a read-only PDF once a month
- A second person signs in and you wrote the sign-in
- There is an invite link and you cannot say today what revokes it
- One member's session can fetch another member's accounts because a query forgot to check
- Anyone in the household would act on a number in it without opening the bank app first
If you build it anyway
the checklist, then the prompt that enforces it
- Use a real identity provider. A multi-user financial app is the worst possible place to practise writing passwords, resets, sessions and MFA.
- Decide tenancy before the first table exists: household id on every row, member id on everything that belongs to a person, enforced with row-level security rather than a WHERE clause you have to remember each time.
- Write the revocation path before the invite path. Removing a member must kill sessions, disable their aggregator items, drop them from every scheduled job, and be one testable command.
- Aggregator tokens live in a separate encrypted store keyed per member, never in a column beside the transactions they unlock.
- Every balance renders its own last-successful-sync timestamp on every member's screen, not only on the screen of whoever linked it.
- Deduplicate joint accounts explicitly by institution and account identifier, and show the collision instead of silently counting a balance twice.
- Encrypted export on a schedule, restored for real at least once. Years of hand-tuned categories are the only thing here you cannot re-derive from the bank.
I am building a shared household finance app: two people, linked bank accounts, one ledger. Apply these before any feature work, and refuse politely if I ask you to drop one.
1. Do not write authentication. Use a hosted identity provider with MFA. If I
insist on my own passwords and sessions, tell me plainly that this app holds
two people's complete financial histories and that generated auth is the
wrong place to save an afternoon.
2. Settle tenancy before schema: household_id on every table, member_id on
everything belonging to a person, enforced by row-level security rather than
a filter each query has to remember.
3. Build member removal before member invitation. Removal must invalidate
sessions, disable that member's aggregator items, and drop them from every
scheduled job and email recipient list, in one tested command.
4. Audit every background job for scoping and show me the list: job name, and
the exact filter it applies. Digests and exports are where forgotten filters
leak data to people who left.
5. Start with CSV and OFX import. Do not add a bank aggregator until I ask, and
when I do, explain what changes about the threat model before writing code.
6. Aggregator access tokens go in a separate encrypted store, keyed per member,
never in a column beside transactions. Never log one, never let one reach a
stack trace.
7. Invite links are single-use, expiring, at least 128 bits from a CSPRNG, and
bound to one email address. Never sequential ids.
8. Every account stores lastSuccessfulSyncAt and every balance renders it, on
every member's dashboard. A stale number with no date is the failure I care
about most.
9. Detect duplicate joint accounts by institution and account identifier and
surface the collision rather than summing the same balance twice.
10. Transactions are append-only. Categorisation lives in its own table with
the member who changed it and a timestamp, so a shared edit is
attributable instead of a mystery.
11. Nothing here writes to a financial institution: no transfers, no bill pay,
no card controls. Refuse if I ask.
12. Build encrypted export and a tested restore before any import path, and say
in the README that if two people make money decisions from this, $14.99 a
month is the correct answer.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 a second login appears. $14.99 a month, or $99.99 a year, covers the whole household with no per-partner charge, and what you are buying is not the charts. It is somebody else's answer to invite revocation, per-member scoping, and the Tuesday a credit union changes its MFA flow — plus a breach process that already exists rather than one you would be inventing at speed. Actual Budget is the honest free middle if you want to own the data without owning the auth.
$14.99/mo is cheaper than your weekend.
Keep the ledger in something openable without your app — plain SQLite with documented columns, plus a monthly CSV per member somewhere off the box. What has to survive a migration is the categorisation history and the account mapping, not the balances; balances re-derive from the bank in minutes and the categories took two people two years. Then answer the awkward question early: if the household splits, who keeps the database, and how does the other person get their own copy of it?
Long-running open-source personal finance manager covering budgets, transactions, rules and reports.
Local-first open-source envelope budgeting with multi-device sync, and the least dangerous way to own this data.
Questions
Copilot Money scores 53 here and this scores 61. What is the difference?
The second person. Copilot's homemade version can be one user on one laptop, where 'my data, my risk' actually holds. Monarch's whole shape is a household — two logins, an invite flow, shared edits, joint accounts, one ledger describing both of you. That converts a personal project into a small multi-tenant service whose auth you wrote, and it ends your right to accept the risk on everybody's behalf.
Can I keep it single-user and just send my partner a report?
Yes, and that is the version worth building. A monthly PDF or a read-only summary keeps everything on one machine, deletes the invite flow, deletes the session handling, and leaves the interesting work — categorisation, cash flow, net worth — completely intact. Most of the risk on this page arrives with the second login, not the second person.
Is bank aggregation the dangerous part?
Half of it. Read-only tokens cannot move money, but they are long-lived, broadly scoped, and they live next to a ledger showing where two people live, who pays them, which pharmacy they use and which lawyer one of them paid in March. The other half is the query you forgot to scope. Neither shows up in a demo.
Does a household app still count as personal use under GDPR?
The household exemption is written for processing with no connection to professional or commercial activity, and a couple's shared budget on a home machine plausibly sits inside it. What does not go away is ordinary security-of-processing duty once you hold another adult's financial records, plus every aggregator's developer agreement, plus the US Safeguards Rule the moment this stops being a hobby. Real duty, not PCI — worth naming honestly rather than inflating.
- FTC Safeguards Rule — what your business needs to know
- GDPR Art. 32 — security of processing (EU)
- GDPR Art. 5 — principles relating to processing of personal data (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.
Your bank feed is read-only. Your database isn't — it's a map of everywhere you go and everyone you pay.
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.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice