Problem
Students manage money on irregular, academic cycles - tuition lump sums, semester allowances, irregular income - yet the tools available assume stable monthly paychecks. The result is blind spending, missed payments, and no historical view of financial behavior.
Context
Many students rely on manual note-taking or generic consumer budgeting apps that do not reflect academic budget cycles, tuition payments, or campus-specific constraints. This project was scoped as a full-stack prototype aimed at realistic adoption: it needed to work on constrained campus networks and low-end phones.
What I Built
A full-stack student finance application that lets users track spending, compare budgets against actuals, and inspect financial behavior over time through interactive visualizations.
- Expense and budget tracking shaped around academic cycles
- Dashboard with interactive charts for spending patterns over time
- Optional real-time sync so active dashboards stay current
My Contribution
Full-stack design and implementation - from data model and API boundaries through to the client interface and visualization layer. I owned every architectural decision and tradeoff documented in this case study.
Architecture
The stack is intentionally simple and maintainable: a JavaScript-driven client, a Node.js API layer, and MySQL-backed persistence for structured financial records. Firebase provides optional sync and real-time updates for active dashboards.
- Client: HTML5, CSS3 (Tailwind CSS), Vanilla JavaScript (ES6+)
- Visualization: Recharts / D3.js for budget-versus-actual and trend views
- API layer: Node.js service with clear, modular domain boundaries
- Persistence: MySQL with constrained transactions for financial records
- Sync: Firebase for optional real-time dashboard updates
Technical Decisions
Key decisions centered on data consistency, offline resilience, and interface feedback:
- MySQL over ad hoc document storage - financial reporting needs structured, constrained transactions; a relational model makes aggregations and integrity guarantees straightforward.
- Modular domain boundaries - budgets, transactions, and reports are isolated behind clear APIs so the backend can evolve without breaking the client.
- Performance-first client - responsive interactions were prioritized for constrained networks and low-end devices.
Difficult Problem
Financial data must remain consistent and legible even when the network is not: a student may log expenses offline, on poor campus Wi-Fi, or across multiple sessions, and the dashboard must never show a misleading or stale picture of their budget.
Solution
I combined MySQL's constrained transactions for source-of-truth records with Firebase's real-time layer for live dashboard updates, keeping writes structured and auditable while making reads feel immediate. Clear domain boundaries meant each concern - recording, reporting, syncing - could be tuned independently.
Review & Active Maintenance
Following the successful deployment of the core system, the architecture is currently undergoing a scheduled technical review cycle focused on structural scalability and feature-based optimizations.
Visual validation assets-including updated dashboard snapshots, optimized budget comparison charts, and the refactored transaction domain layer source code-are being re-captured from the staging environment to document these latest build improvements shortly.
Result
A working full-stack prototype with a clear data model for financial records, responsive interactions on constrained networks, and maintainable backend boundaries - a foundation that supports incremental growth from a student pilot to a broader education finance tool.
What I Learned
Building Stashu reinforced the importance of aligning feature design with actual user constraints, choosing a backend model that fits reporting needs rather than fashion, and making incremental improvements that preserve maintainability.