HomeBudget+ v2: From Manual Tracking to a Smarter Offline-First Budgeting App

Von Ali Pilehvary am 12.09.2026

For my second semester project, I continued working on HomeBudget+, the offline budgeting app I originally built in Semester 1. The first version could track expenses and income, but categories had to be selected manually and recurring payments had to be entered again every month.

This semester, I extended the app with automatic categorization, recurring expenses, transaction search, data backup and a PIN lock. I also investigated real bank integration before deciding not to include it in the final version.

Auto categorization without AI

I wanted the categorization to stay simple, so I did not use a machine learning model or an external API. Instead, I implemented a rule-based system using keyword → category pairs.

For example, a note containing "netflix" can automatically suggest the Entertainment category. When several keywords match, the longest matching keyword gets priority because it is usually more specific.

New keywords can also be added automatically to the rule table. I added a screen where these rules can be reviewed and deleted manually, so the user remains in control of the categorization.

Recurring expenses and a date problem

Recurring expenses store a category, amount, frequency and next due date. During testing, I found an issue with dates such as January 31. JavaScript can turn January 31 plus one month into March instead of the last valid day of February.

I fixed this by changing the month first and then clamping the day to the last valid day of the target month.

Recurring rules can now repeat weekly, monthly or yearly, have an end date or occurrence limit, and be paused or resumed. The user can also preview the next three dates before saving a rule.

Search and backup

As the app started generating more transactions automatically, scrolling through the list was no longer practical. I therefore added search by note text and date range. For example, searching for "spar" shows matching transactions and the results can be narrowed by date.

I also added CSV export and full JSON backup/restore. The JSON backup contains expenses, incomes, budgets, recurring rules and category rules.

Testing the restore process revealed a bug where the learned category rules were exported but not restored. After fixing this, the backup also preserves those rules correctly.

Locking the app down

I added a PIN screen that must be passed before accessing the app. HomeBudget+ also locks itself automatically when it goes into the background.

The PIN is hashed with a random salt and is never stored as plain text. The local SQLite database is also encrypted on the device.

The bank integration I removed

I also investigated connecting HomeBudget+ to a real bank through an Open Banking API, so transactions could be imported automatically.

GoCardless had stopped accepting new signups in 2025, so I tested Enable Banking instead. I created a sandbox application, implemented the required JWT authentication and successfully retrieved test banks through a small Node backend.

The technical problem was not the API itself. The issue was the required backend server. API credentials cannot safely be stored inside a mobile app, so a server would have to sit between the bank and the app. Financial data would also pass through that server.

Since HomeBudget+ has been offline-first and serverless since Semester 1, adding a backend just for bank integration would have changed an important part of the application’s architecture. I therefore removed the feature before the final version.

What I learned

The biggest lesson from this project was not really about one specific technology. It was more about where I should be careful and where I should test things instead of assuming that the simple solution will work.

I trusted some of the “easy” parts too much. The date calculation looked straightforward, and so did the backup and restore process. Both of them ended up having bugs in edge cases that I only found because I tested them directly.

The part I was initially more worried about, the keyword-based categorization, actually worked quite well after I added the priority rule for matching keywords.

I also learned that a feature can change the architecture of a project much more than it seems at first. Bank integration looked useful and technically it was not impossible to build. The sandbox worked on the first real attempt. But adding it would have meant that the application I delivered was no longer really the same application I had been building since Semester 1.

Realizing that before shipping the feature was more valuable than simply having another feature in the app.