I reached the end of sprint 2 with a VantFi that technically worked: you logged income, expenses, debts, goals. The dashboard showed numbers. The backend responded. A success on any technical checklist. Then I gave it to 10 real people and discovered that technically working and solving the user's problem are different things.
The test, no spoilers
I recruited 10 people: 4 close friends, 3 acquaintances from my old office, 3 family members of different ages. I installed TestFlight on their phones, explained the goal was "use it for a week, log what you spend, and tell me when something doesn't make sense". No additional guidance. No tutorial.
Most of them managed to log their first expense on day one. Retention dropped significantly between day 1 and day 7, which is normal for an MVP without polished onboarding. The important thing wasn't the numbers — it was the reasons people dropped off. That was the real gold mine.
Lesson 1: the quick-add wasn't that quick
The flow was: tap the floating button, expense form, type the amount, pick a category, pick the source account, write an optional note, save. I saw it as "5 fields, this is fast". For 6 of the 10 people, that was too much.
I changed it like this: tapping the floating button opens a full-screen numeric keypad, you type the amount (the only required field), tap save. Category is inferred from the last similar expense; the account stays as the one you used most recently; the note is skipped. If you want to edit something later, you open the detail and change it. We went from 5 fields to 1. Logging friction dropped to the point where it feels like writing in a notes app — which was exactly the right metaphor.
Lesson 2: the default categories were from the first world
My initial list was the generic categories of any US finance app translated to Spanish: "Food, Transit, Entertainment, Health, Bills, Other". Testers barely used them. Each person asked me for categories matching how they actually spend money here — day-to-day Colombian terms that don't exist in an imported taxonomy.
We rewrote the default categories from scratch based on those suggestions. This is one of those decisions where customer development wins by a mile against any competitor benchmark: the right words aren't designed on a whiteboard, they're heard.
Lesson 3: the dashboard was overwhelming
My dashboard showed: month balance, donut chart by category, recent transactions list, goals progress indicators, total debts, pending income. All on one screen. To me, the engineer, that density was useful information. To the user who opens the app for 30 seconds on the bus, it was noise.
We simplified it to three big cards: "How much you spent today", "How much you have left this month", "Your next big payment". Everything else moved to separate screens accessible from the menu. The metric that measures if this version works: how long it takes a user to understand where their month is with a single glance. Before: ~8 seconds of reading and processing. Now: ~2.
Three bugs nobody saw coming
Bug 1: if the user changed phone language to English while the app was open, months showed in a mix of both. Cause: DateFormat cache wasn't invalidated on locale change. Fix: invalidate on system event.
Bug 2: logging an expense at 23:59 grouped it into next month because the server was in UTC. Cause: I was storing the timestamp and grouping server-side without offset. Fix: user offset travels with each record, grouping respects their timezone.
Bug 3: two people had more than 200 transactions to import from a bank export. The app wouldn't load them. Cause: silly limit on the import endpoint. Fix: pagination + visible progress bar.
What's next
Sprint 4 is going to open the public waitlist. The product isn't ready for everyone, but it's ready for 50-100 more people, which is what I'll be looking for. The "ready for production" criterion is still: I use it every day without frustration. We're not there yet, but we're much closer after this sprint.