Building The Records App: A Dev Log

The Records App started because my friends and I were terrible at tracking money.

We had a WhatsApp group called “House Finances” where someone would send a message like “paid 15k for water bill, everyone owes 3k.” Then that message would get buried under memes and voice notes, and two months later nobody could remember who paid what. We tried spreadsheets. We tried note apps. Everything fell apart because nobody wanted to maintain it.

So I built something. The Records App is a savings and expense tracker that actually stuck. Here is how it went.

The first version was terrible

I started with React, TypeScript, and a vague idea of what I wanted. The first version had no auth — just a single shared page where anyone could edit anything. I thought that was fine for a small group. It was not fine. Someone accidentally deleted a month of records, and I had no way to recover them because I also had no backup strategy.

Lesson learned the hard way: if people are entering data they care about, you need auth and you need backups. There are no shortcuts here.

The tech stack, and why

I went with React and TypeScript on the frontend, Node.js and PostgreSQL on the backend. Nothing fancy. I picked these because I actually know them, not because they are the optimal choice for a savings tracker.

There is a temptation when starting a new project to use it as an excuse to learn a new framework. I have fallen for that before and it always doubles the timeline. This time I wanted to ship, not learn. I could experiment on something else.

Tailwind CSS for styling, because writing my own CSS classes for form inputs is not how I want to spend my weekends.

The hard part was not the code

Getting the CRUD operations working was straightforward. User signs up, creates a group, adds transactions, sees a dashboard. Standard stuff.

The hard part was the logic around settlements. When five people are sharing expenses unevenly over several months — some people paying rent, others covering groceries, someone spotting cash for a taxi — figuring out “who owes who and how much” gets complicated fast.

My first attempt was a simple running tally. Person A has paid X total, their share is Y, so they owe or are owed Z. That works until people start making partial payments, or someone leaves the group mid-month, or two people settle up outside the app.

I ended up rewriting the settlement logic three times. The version that works treats every transaction as a ledger entry and calculates net balances from scratch each time. Not the most efficient approach, but it is correct and I can actually debug it when something looks wrong.

Things I would do differently

Start with the data model. I designed the UI first and then tried to make the database fit. That led to awkward workarounds and a migration I would rather forget. If I could redo it, I would start by sketching out the tables and relationships on paper before writing any frontend code.

Add tests earlier. I have no automated tests. I tested everything manually, which worked when the app was small but became painful as features piled up. Every time I changed the settlement logic, I had to manually re-check a dozen scenarios. That is time I will never get back.

Deploy sooner. I waited until the app felt “ready” before putting it online. That took months. Meanwhile, my friends were still losing track of expenses in WhatsApp. I should have deployed the ugly first version and improved it live. Nobody cares about polish when the alternative is a group chat.

It is live and people use it

The app is at saving.uwe.rw and my friends actually use it. That still feels surreal. Something I built from scratch, running on a server, with real people depending on it to track real money.

It is not perfect. The mobile experience needs work, the dashboard could show more useful summaries, and I want to add recurring expenses at some point. But it works. People open it, add their transactions, and trust the numbers.

That is the best feeling in this job — when something you made becomes part of someone’s routine. Not because they have to use it, but because it actually solves their problem better than the alternative.

The source code is on GitHub if you want to look. Fair warning: you will find at least three things you would have done differently. That is fine. So would I.