BudgetBuddy – Student Expense Tracker

College students juggle UPI payments, canteen bills, recharges, and travel costs with no simple way to see where money goes. Most expense apps need installation, internet, or sign-up — overkill for a quick daily check. Students need a zero-friction tool that works offline, starts instantly, and answers one question fast: am I going to run out of money before month-end? I built a command-line tracker with zero setup, since most students already live in a terminal for coursework and don't want another app eating storage or asking for data. Process I started with the four required features (add, view, total, top category) using lists of dicts as the brief required — no database. First pass had a flaw: any bad input (wrong date format, non-numeric amount) aborted the action and dropped the user back to the main menu. I tested this by deliberately entering garbage into every prompt and found it broke the experience fast. I rebuilt input handling so every field loops until valid instead of failing once. I also wrapped the main loop in a try/except for Ctrl+C and EOF, since a raw traceback looks broken even if the logic is fine. For the bonus, I went beyond a simple budget check: spending now ties back to the top category with a 0-100 health score, so the warning explains itself instead of just flashing a number. Results Tested 6 edge-case scenarios end-to-end: invalid dates, non-numeric amounts, wrong categories, invalid menu choices, and Ctrl+C/EOF mid-input. Result: 0 crashes across all 6 — every case now re-prompts cleanly instead of throwing an error. Feature count went from the 4 required to 8 total (4 core + 4 insight-driven additions: percentage breakdown, category ranking, budget health score, and a recommendation that reads real data instead of a hardcoded string). Next time I would add CSV persistence so data survives between runs. Reflection I'd add CSV persistence first — right now data resets every time the program restarts, which is the most obvious limitation for real daily use. I'd also expand categories beyond the four listed in the brief (e.g. entertainment, shopping) since real student spending doesn't fit neatly into four buckets. Given more time, I'd write actual unit tests instead of manually scripting input sequences to check for crashes — manual testing worked here, but it doesn't scale as the feature set grows.