Case Study
BUDGIE
Context
Budgie is for low-to-upper-middle-class users who want to track their finances with precision—manually, without handing it off to automation or wrestling with confusing spreadsheets. It's a back-to-the-basics approach that most budgeting apps miss. Where others pile on automation, bloated features, and endless upgrades, Budgie strips away the clutter and keeps what you need: a simple, intuitive interface for tracking monthly finances and managing savings goals—no extra apps, spreadsheets, or notepads required.
Plenty of budgeting apps claim to be the best because of some fancy feature. Budgie takes the opposite approach. Every feature is designed to be simple and low-friction, because budgeting is already a big weight on many people's shoulders—and too often, beginners give up when it feels confusing, stressful, and overwhelming. Budgie is built so they don't have to.
The Problem
Most budgeting apps fall into one of two camps: automated tools that sync to your bank but feel like a black box, or spreadsheets that offer total control but require continual maintenance. I wanted something in between — an app that respects manual budgeting as an intentional choice, not a fallback, while also removing the friction that makes spreadsheets overwhelming to maintain.
Core Features
Monthly budgeting
Users allocate expected income across categories each month, with built-in tracking against what's actually been spent.
Expense tracking
A streamlined flow for logging transactions and tying them back to budget categories in real time.
Savings funds
Users can create individual funds for specific goals. Funds can be archived, and each one maintains its own transaction history.
Financial overview
A dashboard view that ties budgets, funds, and accounts together into a single overview for where things stand.
Authentication
Secure JWT-based auth with proper session handling across a cross-origin frontend/backend split.
Architecture
A full-stack build using React + TypeScript on the frontend, Node/Express REST API on the backend, and PostgreSQL for relational data, JWT for secure authentication, and BCrypt for password hashing. Deployed using Vercel (frontend) + Railway (backend) + Railway Postgres setup for the production version.
What I'd Do Different
The main thing I'd do differently if I were to start the project over is I would spend more time on the UX/UI design, especially for the mobile version; I would prioritize a mobile-first approach to ensure that the app is primarily built for phone-users and secondarily built for desktop users, not the other way around.
Additionally, I have a future feature in mind where I would integrate Plaid in the app; however, this would not be for the usual purpose of integrating Plaid into a budgeting app (automatic transaction categorization, which is often inaccurate). Instead, the idea is to have a pop up every time a transaction from the bank shows up, which would simply show the transaction and underneath each category budget for the month, where the user can click one button to categorize the transaction. This would provide seamless bank integration while ensuring there are no errors errors due to faulty automated categorization.
