netSum

• 

  Home Screen

• 

  Charts

Inspiration

I used to track my money by noting every transaction in a WhatsApp chat. It worked until it didn't: a forgotten coffee, an unrecorded ATM withdrawal, and suddenly my notes no longer matched the cash in my wallet. Nothing in that chat ever told me something was missing.

I wanted a tool built on one rule: the day can't close until the mismatch is resolved. If what I count and what the app calculates disagree, I have to find out why before moving on.

What it does

netSum is a personal finance PWA that tracks money per payment method: cash, a bank account, a metro card, or anything else you add.

• Daily logs: record a Spend (an expense, loan payment or saving deposit), an Income (salary or money paid back, with its source; income goes to Cash or Account only) or a Transfer between your own methods, like an ATM withdrawal. Logs can be edited or deleted while the day is open.
• Day-close gate: at the end of the day, you count what you really have in each method and type it in. If any real balance differs from the calculated one, netSum shows the difference per method in red and refuses to close the day until they match. That mismatch usually points straight at the forgotten transaction.
• History: closed days become read-only statements, and each new day opens at the previous day's real balance.
• Loans, savings and goals: track remaining loan balances and savings growth, and set a saving goal with a daily limit for non-essential spending, shown on Home.
• Charts: income, spend and net overview, income vs spend by month, spend by expense and by payment method, and income by source.
• Built for phones: installable, with a bottom tab bar and a light/dark theme that follows your system by default.

How I built it

• Frontend: React and Vite, with Recharts for the charts and vite-plugin-pwa for installability, deployed on Vercel.
• Backend: Python 3.11 and FastAPI with supabase-py, deployed on Render.
• Database: Supabase Postgres.

I planned the project in scope, PRD, spec and checklist documents (in the repo's devpost/ folder) and used Claude Code to build against that plan. The plan then changed as I used the app. I added a light/dark theme with a toggle, restricted income to Cash and Account, and extended the first spend-only version with income and transfers.

A few design choices shaped the build:

• Balances are never stored. They are always calculated from the logs, so there is no second copy of the truth that can drift.
• The day-close rule lives only in the backend (balances.py and the days route), so the frontend can't bypass it.

Challenges I ran into

• Making balances trustworthy. A finance app is worthless if the arithmetic is off by a cent, so I had to keep float math out of the calculations and convert values carefully where the database hands them back.

• Modeling money that moves. The first version only handled spending. Adding income and transfers meant rethinking how balances are calculated per method, plus a migration for the existing database.

• Slow responses and 500 errors under concurrent requests. Once the app loaded several screens at once, requests got slow and some failed with 500 errors. I tracked it down and fixed it in the backend's database layer.

• Keeping the rule in one place. It was tempting to check the day-close in the UI for speed, but that would have left two copies of the rule. Keeping it only in the backend took more careful API design.

• Making a strict app feel friendly. A gate that blocks you is only useful if it doesn't feel punishing, so I spent time on clear per-method differences shown and highlighted in red.

Accomplishments that I'm proud of

• A complete, deployed, installable app that solves a problem I actually had, not a demo mockup.
• A day-close gate that turns "my notes feel off" into a specific, fixable number per payment method.
• A calculated-not-stored balance model with exact decimal handling.
• Building it solo, with planning docs and tests alongside the code.

What I learned

• Designing around a single source of truth (the logs) makes everything else, from history to charts, simpler and more reliable.
• Exact money handling has to be decided on day one, because it touches the database, the API and the UI.
• Writing the scope, PRD and spec first made working with an AI coding assistant far more effective, because it had a clear plan to build against. The plan still had to change once I used the real app.

What's next for netSum

• A Settings screen to add or change payment methods after onboarding (today they are set only during onboarding).
• Reminders for things I need to pay.
• Bill sharing with friends.
• An AI-powered saving-goal feature that suggests daily limits from real spending patterns.
• Editing of past days, with a clear record of what changed.

Built With

• fastapi
• postgresql
• python
• react
• restapi
• supabase