Building a Finance Dashboard Around Questions, Not Charts
Budgeting is rarely a data problem. It is usually a visibility problem. People know money is coming in and going out. They often do not have a clean way to see patterns over time.
That was the starting point for this finance dashboard. Not building a trading terminal. Not pretending mock data was a fintech product. Just building a clear system for exploring income, expenses, and savings through a few useful views.
Start With Questions, Then Build Components
I did not begin with charts. I began with questions. Where is money going. How does spending shift by category. Is savings improving month to month. Each component came from one question.
That led to a simple architecture in Next.js. Transaction data came through an API route backed by mock JSON, then reusable components transformed it into different views instead of duplicating logic.
- Pie charts aggregated expense categories to show spending concentration
- Monthly bar charts compared income against expenses instead of showing each in isolation
- A sortable transaction table acted as the raw layer beneath the visual summaries
That layering mattered. Charts gave signal. The table gave auditability.
Type Safety Was Part of the Project
One thing I cared about early was not treating validation as cleanup after the fact. Zod sat in the API layer from the start. TypeScript models shaped the rest of the code. For a small project, that discipline was useful.
Accessibility also ended up being a more interesting problem than I expected. Keyboard sortable table headers were a small detail, but details like that change whether a dashboard feels considered or assembled.
What Stayed Intentionally Simple
The data is hardcoded. That was deliberate. This was not trying to solve persistence, auth, or multi user sync. It was an exercise in interface structure and data presentation.
Some limitations came with that. There is no drill down interaction. No pagination. No live data source. Some people would see those as missing features. I saw them as boundaries that kept the project focused.
What I Would Change
I would push interactivity further. Click a category and filter the whole dashboard. Connect charts so one interaction reshapes the rest of the view. Right now the components coexist well, but they do not really talk to each other.
I would also replace static thresholds like simple savings rate displays with better handling for edge cases. Negative savings should probably communicate stress, not just show a number.
One honest rough edge is that mock data can hide design problems. Real messy financial data would have exposed more.
What It Represented
This project was less about personal finance and more about learning how to structure a small full stack application cleanly. API route, validation, reusable visualization components, modest scope, but real engineering choices.
Good dashboards do not start with charts. They start with questions.