BudgetPulse

Many students and first-time earners struggle to manage monthly budgets because most expense trackers only record spending after it happens. The key pain point is the lack of early warnings that help users avoid overspending before month-end. For example, a student with a monthly budget of Rs 20,000 may spend Rs 9,500 in the first 10 days without realizing they are on track to exceed their budget. This project addresses that gap by combining expense tracking, budget monitoring, spending forecasts, financial health scoring, recurring expense management, and alerts, transforming a passive expe Process I started by mapping out what a typical student actually needs to track money — not a generic ledger, but something that warns them before they overspend. So instead of building "add/view/delete expense" first, I designed the data model around a budget object from day one, so every feature could check against it. I built incrementally: core CRUD → budget logic → forecasting → health scoring → recurring expenses → undo/backup → multi-profile. Each layer was tested against the previous one so I wasn't bolting features onto a fragile base. For the forecast, I went with a simple linear projection (days passed ÷ days in month × spend) rather than anything fancier, because accuracy was less important than giving students an early, honest warning signal. Results The system correctly caught a budget breach the moment it happened — flagging a ₹50 overage instantly rather than after the fact — and the forecast engine predicted a ₹220 end-of-month overrun while only 25 of 30 days had passed, which matched my manual calculation exactly. The Financial Health Score dropped from 100 to 35 in direct response to the overspend, confirming the live-recalculation fix actually worked. Search/filter, recurring expense tracking, undo, and backup/restore all performed correctly in a full session test with no data corruption across profile switches. Reflection I'd write automated tests before building each feature, not after — the health score bug only surfaced because I was testing by hand, and a proper test suite would've caught the stale-state issue in minutes instead of a full refactor. I'd also design the forecasting model to be swappable (linear now, but pluggable for weighted/seasonal models later) instead of hardcoding the formula, so the app can grow more accurate without a rewrite.