Skip to project
← Projects

PROJECT_02 / Full-stack development

Expense Recorder

A connected workflow for transactions, budgets, and financial review.

STACKNext.js · React · Flask · Python · PostgreSQL · Supabase

01

Overview

The application connects income and expense records with planning and review. Budgets, savings goals, recurring bills, credit accounts, and trip groups share a monthly workflow instead of living in separate trackers.

My contribution

I built the frontend, Flask API, database integration, and reporting workflows, expanding the application from expense entry into a broader monthly finance tool.

02

User workflow

The core workflow moves from entering financial activity to reviewing its effect on the month. Dashboards and PDF reports provide different views of the same recorded information.

  1. 01Record activity
  2. 02Submit to API
  3. 03Store records
  4. 04Review totals
  5. 05Export report
03

Application architecture

Next.js provides the user interface, Flask handles backend requests, and PostgreSQL stores structured financial data. The project moved from a local database to Supabase-hosted PostgreSQL; Supabase also supports authentication.

  1. 01Browser / Next.js
  2. 02REST API
  3. 03Flask / Python
  4. 04PostgreSQL / Supabase

Technical decisions

Separate interface and services

The frontend can focus on entry and review while Flask handles data processing behind an API boundary.

Keep financial records relational

PostgreSQL supports the relationships between monthly records, categories, budgets, and linked activity.

04

Data model

Transactions belong to monthly records and categories. Budgets provide planning context, while recurring bills and trip groups connect related activity. This is a conceptual view of the workflow, rather than a database schema export.

  1. 01User / monthly record
  2. 02Transactions
  3. 03Categories & budgets
  4. 04Bills / trip groups
05

API design

The Next.js client sends requests to Flask services that process expense records and connect the interface to persistent storage. Keeping that boundary explicit makes the path from a form to a saved record easier to understand and debug.

06

Interface & reporting

The dashboard provides an overview; category breakdowns and report views support a closer review. Screenshots show different parts of the financial workflow.

07

Technical challenges

01

Connecting recurring activity

Problem
Bills and linked expenses need to stay consistent within the monthly record.
Approach
Treat related activity as part of the same workflow rather than isolated entry forms.
Result
Support recurring obligations alongside everyday recordkeeping.
02

Growing beyond expense entry

Problem
Budgets, savings, credit, and trips introduce different relationships and review needs.
Approach
Organize the application around monthly records with shared reporting surfaces.
Result
Bring operational entry and analytical review into one application.
03

Changing persistence environments

Problem
The initial local PostgreSQL setup needed a managed hosting path.
Approach
Migrate the database integration to Supabase-hosted PostgreSQL.
Result
Retain relational storage while adding managed data and authentication services.
08

Result & lessons

The tool evolved into a usable personal finance platform with budgeting, recurring obligations, savings, credit tracking, trip spending, PDF reports, and audit logging.

  • Model related financial activity before adding more screens.
  • An explicit API boundary makes the end-to-end data path easier to reason about.
  • Entry and review need different interfaces, even when they share the same records.