2025 · EARLY DEVELOPMENT · BUDGET & FINANCE APP
Offline Budgeting App
A personal finance app focused on clearer budgeting and quicker affordability decisions.
What It Is
An offline budgeting and finance app focused on clearer planning, faster conversions, and everyday affordability.
Why I Made It
The main reason for building it was that the budgeting and finance apps I looked at did not really work the way I wanted them to. A lot of them were built around connecting to a bank account, scanning transactions, and then filtering everything afterwards, which felt more awkward than useful. Most of them also assumed monthly income and monthly budgeting, while I am paid weekly, so even basic planning often meant converting everything manually.
Design Direction
A big part of the app is making those conversions easier to understand. The goal is to let a user enter what they earn weekly, add both weekly and monthly expenses, and then quickly see how much money is left over in either view. It is also designed to help answer more practical questions, like how much needs to be set aside each week to cover monthly costs, how much something would really cost over a year, or whether a monthly payment is actually affordable when income is being thought about week by week.
Why Offline
The app is designed to work offline so that financial data stays on the user’s own hardware rather than being pushed into a cloud service. That feels more trustworthy, and it also means the app can be used without relying on an internet connection every time someone wants to check or adjust their budget.
Future Direction
Although a lot of the app is already built, it still sits in early development and needs more work before it feels complete. The next steps would be to return to it, refine the interface, make the budgeting flow clearer, and continue shaping the conversion and affordability features into something more polished and reliable. Longer term, the aim would be for it to feel like a practical budgeting tool that solves the specific gap that pushed me to build it in the first place, rather than just becoming another generic finance app.
Architecture
Interface Structure
The app was organised around a persistent sidebar and a main selected-screen view, so the structure stayed clear while moving between different parts of the budget. The overview was built around a waterfall graph, tying into the water theme behind the name Inflo and giving the app a more visual way of showing financial flow.
Budgeting and Breakdown Views
Both the income and outgoings sections were built around list views showing existing entries, along with add controls for creating and managing them. The overview grouped financial data by category, making it possible to see how much each category cost for the selected frequency, and then expand that view to break the category down into individual items.
Debt Planning
The app also included a debt-management screen where a user could select current debts and decide how much to allocate toward them, either from an existing outgoing, a custom amount, or free unallocated cashflow. It then presented the result as a card-based view showing projected payments, how long repayment would take, and when the debts would be cleared. Different repayment strategies could also be chosen, such as prioritising the highest APR or the lowest debt first.
Profiles and Settings
The app supported up to five separate user profiles, each with its own financial data kept separate from the others. It also included settings for things like currency selection, graphics options, and other app-level preferences.
Event and Animation System
Part of the app was built around an event bus and an animation bus so the interface would feel smooth and responsive rather than stuttery or low-FPS. The event bus handled click-driven behaviour, listeners, and interaction flow without overloading the main thread, while the animation bus prepared the data needed for animation work in advance so the main thread mainly had to apply the values where they were needed. Data was also added and removed through an SPSC ring buffer, helping keep the system lightweight and responsive.