← All work
27
People using it

A dashboard that organises your spending at the start of every month, so you have a clear view of where it goes and a record you can go back to.

Project Type
Personal Project
Stack
ReactTypeScriptPostgreSQLTailwind
Year
2026
Status
Live
Website
budgettr.com

Case study

  1. Overview

    Budgettr, a personal project I designed and built end to end. It is a monthly spending dashboard in React, TypeScript, PostgreSQL and Tailwind, live in Arabic and English.

  2. Problem

    My own spending was scattered across the month with no single view of it. Tracking expenses meant flipping between notes and bank statements, and a savings goal stayed a guess instead of something I could measure.

  3. Research

    I tried the existing budgeting apps first. None of them handled Arabic and English or SAR the way this needed, and they were built around logging a transaction rather than around the month as a cycle. Once other people started using it, their first screens became the second round of research: what a new account looks like with nothing in it yet.

  4. Process

    I built it around a monthly cycle, setting income and categories at the start, logging expenses against them, and watching the savings goal update as the month runs. Wrapping an existing app was the alternative I dropped, for the reason above. The first version treated empty screens as an edge case and they read as broken, so every empty state was rebuilt to name the action that fills it and to hold totals at SAR 0.00 instead of going blank.

  5. Result

    A live dashboard covering income, category budgets, bills and goals in both languages, with dark and light mode. The shots below run in two groups: the app with a month of data in it, then the empty states a new user actually starts from.

  6. Impact

    27 people use it, and it is my own daily tool, which is where the bill reminders and the empty states came from in the first place.

  7. Takeaway

    Using something you build yourself every day surfaces the small annoyances a spec would never catch. What I would change: build the empty states first rather than last, since they are the first screen every new user sees and they were the last thing I designed.

The app with a month of data in it

Dashboard: the month's net, income against expenses, every budget category's progress, bill reminders, and goal progress on one screen.
Dashboard: the month's net, income against expenses, every budget category's progress, bill reminders, and goal progress on one screen.
Transactions: each entry with its category, note and date, filtered by month, category and type, with income, expenses and net recalculated above the list.
Transactions: each entry with its category, note and date, filtered by month, category and type, with income, expenses and net recalculated above the list.
Budget: a ceiling per category with spent, remaining and percentage. The bar runs green while there is room and turns amber as the category approaches its limit.
Budget: a ceiling per category with spent, remaining and percentage. The bar runs green while there is room and turns amber as the category approaches its limit.
Bills: a month calendar over a due list. Each bill is tagged overdue, due in N days, or paid, and clears in one click.
Bills: a month calendar over a due list. Each bill is tagged overdue, due in N days, or paid, and clears in one click.
Goals: saved against target, percentage, days left, and the contributions logged against each goal.
Goals: saved against target, percentage, days left, and the contributions logged against each goal.

Empty states, because a new user's first screen has no data in it

Empty dashboard: totals read SAR 0.00 rather than going blank, and the budget card offers the action that fills it instead of an empty chart.
Empty dashboard: totals read SAR 0.00 rather than going blank, and the budget card offers the action that fills it instead of an empty chart.
Empty transactions: the filters stay in place and the message names the reason, no transactions match these filters, so the screen never reads as broken.
Empty transactions: the filters stay in place and the message names the reason, no transactions match these filters, so the screen never reads as broken.
Empty budget: both cards name the button that fills them, so the next step is never a guess.
Empty budget: both cards name the button that fills them, so the next step is never a guess.
Empty bills: the calendar still draws the month, so the shape of the page is learned before any data arrives.
Empty bills: the calendar still draws the month, so the shape of the page is learned before any data arrives.
Empty goals: one card, one sentence, and the total above it reading SAR 0.00.
Empty goals: one card, one sentence, and the total above it reading SAR 0.00.