Budgeter
2024
Why I built it
Budgeter started with a modest goal: make it easy to see where a monthly budget is going without turning personal finance into a dashboard full of charts. A user can organize spending into categories, record transactions, and compare what has been spent with the budget that was set.
The small scope made the project a useful place to think about the boundaries of a full-stack application. A budget is not just a number on the screen. It is connected to a user, a month, a set of categories, and the transactions that change each category's balance.
How it works
The client is built in React and the API in FastAPI. The backend separates authentication, users, budgets, categories, and transactions into their own routes. SQLAlchemy maps those concepts to the database, while Alembic keeps changes to the schema reproducible.
That separation matters most when a simple action crosses several parts of the system. Adding a transaction, for example, changes the history a user sees and the amount remaining in a category. Keeping the calculation in the API rather than recreating it throughout the interface gives the application one source of truth.
What I learned
I originally used Flask for the backend and later replaced it with FastAPI. The rewrite was less about raw speed than about making the API easier to understand: request schemas, route contracts, and generated documentation made mistakes more visible while I was still building.
The project also taught me that a clean interface often depends on fairly unglamorous backend work. Database migrations, authentication, and predictable error responses do not appear in a screenshot, but they decide whether the interface remains simple as the application grows.