FinanceGuy

What I set out to build

Most finance apps are good at explaining where money went after the fact. I wanted to experiment with a product that could also help around the decision itself, while still doing the normal work of tracking transactions, patterns, and personal financial context.

My contribution

• Worked across the mobile product, frontend, backend, and data layers as co-founder and lead developer.
• Built transaction imports, review, categorisation, and duplicate handling.
• Connected budgets, goals, and spending-pattern guidance to Supabase-backed data.
• Experimented with ML features alongside the existing rules-based workflows.

Problem & approach

FinanceGuy became an end-to-end product rather than a single ML feature. I worked across the mobile interface, authentication, data model, transaction workflows, analytics, and experiments around personalised ML-driven insights. A lot of the useful learning came from the unglamorous parts: edge cases, data quality, product decisions, and getting separate pieces to behave like one application.

How it works

1. 01

   Bring in transactions

   Bring user/transaction data into the application.

2. 02

   Store & organise

   Store and organise it in a personal-finance data model.

3. 03

   Calculate patterns

   Calculate useful financial summaries and behavioural signals.

4. 04

   Calculate guidance

   Use budget pressure and recurring spending patterns for current guidance. The separate LightGBM training experiment uses synthetic data.

5. 05

   Show guidance

   Surface the result through a mobile interface aimed at an actual decision.

Data & evaluation

Data & inputs

Transaction imports, category history, budget cycles, and user-entered goals. The separate LightGBM experiment uses synthetic training data.

How it was evaluated

Current spending guidance is based on rules and patterns. The experimental Python training path writes a placeholder ONNX artifact; it is not a validated deployed ML model.

Results & progress

In development

Product status

Mobile + web

App & product site

Experimental

ML work

• Built transaction import, review, categorisation, and duplicate-handling workflows.
• Connected budget-cycle calculations and goals to Supabase-backed data.
• Kept the product site available while the mobile application continues in development.

Screenshots

View full size

Limits & lessons

Limitations

• The mobile application is still in development.
• Current spending guidance uses rules and patterns. The experimental LightGBM path writes a placeholder ONNX artifact and is not a validated deployed model.

What I learned

• FinanceGuy taught me that product engineering is mostly about trade-offs. A clever model does not matter if onboarding is confusing, the data is unreliable, or the feature does not help at the moment the user needs it.

Next steps

• Keep simplifying the product around the decisions that are actually useful to users.
• Improve data reliability and personalisation.
• Measure whether interventions help instead of adding features for their own sake.