Overview
Expense Tracker began as a practical project for recording trip expenses. I used the two-day deadline to define, build and deploy the smallest useful full-stack version.
The project focuses on the core expense flow rather than a complete personal finance platform. It was also an experiment in AI-assisted development, with a documented scope and incremental implementation.
Problem
People often need only a simple way to record spending, assign categories and review expenses later. The application needed to support that flow while remaining small enough to design, build and deploy within two days.
Solution
Expense Tracker supports the essential expense-management flow. Users can create an account, sign in, add expenses, edit or delete them, assign fixed categories and review their own history.
The repository is designed to be cloned and deployed with a user’s own database and environment. The public deployment demonstrates the project without turning it into a service that stores other people’s financial information.
Key Features
- User registration and authentication.
- Protected application routes.
- Create, read, update and delete expenses.
- Fixed categories and optional notes.
- User-level data isolation.
- Profile view.
- Loading, empty and error states.
- Responsive interface.
- Cloneable repository for personal deployment.
- Separate production deployment of the frontend, backend and database.
Technical Approach
Expense Tracker uses a separate React frontend and Flask backend. The frontend handles authentication, protected routes and expense interactions, while the REST API handles authentication and CRUD operations.
PostgreSQL stores expenses and associates each record with its owner. JWT authentication protects private API operations, and backend authorization ensures users can access only their own data.
Vercel hosts the frontend, Render hosts the Flask API and Supabase provides PostgreSQL. The architecture avoids dependencies that were not required for the two-day MVP.
Engineering Decisions
Keeping the scope small
With two days available, features were evaluated against the core expense flow. Authentication, expense CRUD, categories and user isolation stayed in scope; advanced finance features were postponed so the application could reach production.
CRUD-first architecture
A simple CRUD model matched the product requirements and avoided abstractions that would have added development time without improving the MVP.
User data isolation
Every expense belongs to an authenticated user. Backend operations validate ownership instead of relying on the frontend to restrict access.
Fixed categories
Categories use a predefined set. User-managed categories would have increased the data model and interface complexity without being necessary for the two-day MVP.
Separate frontend and backend
The independently deployed frontend and API made the project useful as both an expense tracker and a full-stack deployment exercise.
Clone-and-adapt model
The repository can be cloned and connected to a separate database and deployment environment. This keeps the project reusable without requiring the public application to operate as a financial-data service.
Challenges
The main challenge was balancing speed with structure. I defined the minimum product and implementation path before coding instead of using the deadline as a reason to skip documentation.
Deployment was the least familiar part. Configuring the frontend, backend and hosted PostgreSQL database across separate services required working with environment variables, production connections, backend configuration, migrations and differences between local and production environments.
What I Learned
Expense Tracker showed me the value of a strict scope and a deployed small product. It gave me practical experience configuring a React frontend, Flask API and hosted PostgreSQL database for production.
AI assistance was most useful when each step had a specific objective and I reviewed the result before continuing. The deadline also gave me practice postponing good ideas when they were not required for the current goal.
Future Improvements
Potential improvements include:
- Budget creation and tracking.
- Subscription and recurring-expense management.
- Spending analytics and visualizations.
- Trips, tags or other ways to group related expenses.
- Automated testing and API documentation.
- Architecture diagrams and improved technical documentation.
- More refined UX/UI.
- Additional filtering and reporting capabilities.
Future features should continue to solve a clear user problem rather than being added only because they are possible.