Budget G.P.A.

The first weight set (45% adherence) over-rewarded people who were good at predicting their own spending, regardless of whether their finances were actually healthy. The rebalance to 35/25/15/15/10 raised Financial Safety and Needs vs. Wants (the pillars that measure real financial position) and demoted pure planning accuracy.

• Proration that matches reality: fixed costs like rent hit on the 1st and are never prorated mid-month; variable categories are paced, with penalties damped early in the month when one grocery run looks like a blowout.
• One-sided savings scoring: over-contributing to a savings goal never lowers a grade. The failure mode of a naive “distance from budget” score is punishing people for saving too much.
• GPA band integrity: the 4.0 GPA interpolates within each letter’s band and never crosses into the next grade’s territory, so the letter and the number can never disagree.
• The philosophy in one line, stated in onboarding: spend as close to your budget as possible without going over.

Testing against my own live bank data broke the app in a way synthetic data never had: credit card payments, moves between accounts, and card-payment “thank you” credits inflated both income and spending. A grade computed from inflated numbers is worse than no grade.

The fix was structural, not a filter: transactions have a third state, transfer, alongside income and expense. Own-money movement is excluded from income, from spending, and from every pillar. Sync marks likely transfers automatically; the review screen shows them as “Transfer: not counted” with a one-tap promotion for the exceptions (a deposited check or a gift really is income).

Critically, the same exclusions were then propagated server-side into alert evaluation and subscription detection; otherwise the app would refuse to count a transfer in your grade while happily sending you an overspend alert about it.

A brand-new user has no spending history, no income data, and no forecast to check. Early versions quietly scored missing pillars as perfect, which meant every new user started with an inflated grade that could only fall. The first week of using the app felt like getting worse.

• Pillars without enough data are excluded and the remaining weights renormalize; the grade reflects only what’s actually measurable
• The report card says so explicitly: “Provisional: 3 of 5 pillars”
• Pillars with no data persist as null in history, never as a fake 100
• Report Card Day recomputes the completed month before celebrating it, and streak logic only counts completed months

Onboarding shows a sample report card instead, so the first real grade is a moment of information, not deflation.

A security review of my own code found that the paid flag was client-writable; any user with the anon key could mark themselves Pro. Worse than lost revenue: Pro includes AI classification, so a bypass would burn metered API spend on my key.

• The flag is now server-owned: a database trigger rejects client writes; only the RevenueCat webhook (signature-verified) can set it
• Lifetime slots are race-safe: the 500/year counter decrements under a Postgres row lock, so two simultaneous purchases can’t both claim slot 500
• Plaid billing is unwound properly: account deletion calls Plaid’s item removal before deleting the token, in the right order; the original code nulled the token first, orphaning the item so Plaid would bill for it forever

All three were found by running structured reviews against my own finished code, the same discipline I’d apply to someone else’s.

Transaction classification has three trust tiers, and only the first writes without asking:

• User rules auto-apply: if you told the app Kroger is Groceries, that’s a fact, not a guess
• Claude’s classifications are suggestions: queued in Review Transactions with bulk accept, never silently written into your grade
• Everything else stays uncategorized, and is counted in the grade with a visible “+$X uncategorized” disclosure, because letting unclassified spend vanish from the score was effectively grade inflation

Debt payments get special handling: auto-labeled, linked to their debt, and treated as spending, excluded from the AI pipeline entirely so a loan payment can’t get misfiled as dining out.

Every stack choice optimizes for one person shipping and operating the whole product:

• Expo / React Native: one TypeScript codebase for iOS and Android, EAS handles signing and builds, and the scoring engine is a pure TypeScript module that runs on-device and is unit-testable in isolation
• Supabase: Postgres with row-level security replaces a whole backend authorization layer; Edge Functions host every operation that touches a secret
• No third-party key ever ships in the app: Plaid, Claude, and RevenueCat server credentials live exclusively in Edge Function secrets
• RevenueCat over DIY receipts: refunds, grace periods, and cross-platform restore are a minefield with no upside to hand-rolling at this scale

Trade-off accepted: vendor dependence on Supabase and RevenueCat. For a solo product, operational simplicity beats theoretical portability, and both have clean exits (it’s Postgres underneath; the purchase model is three products and one entitlement).