Budget Flow: designing and building a local-first finance app

The product

Budget Flow turns bills, paydays, spending, goals, debt and shared expenses into one picture and then projects forward. It ships for iPhone, Android and Mac, requires no account, shows no advertising, and keeps data on the device.

Three decisions that shaped everything else

1. Model relationships, not categories

   Most budgeting tools split money into isolated trackers — a bills list here, a goals list there — and leave the person to reconcile them. Budget Flow connects them: a change to a recurring bill moves the forecast, which moves what a goal can absorb. The interesting information lives in the relationships, so those are what the data model represents.

2. Forecast forward rather than report backward

   Retrospective categorisation tells you what already happened, which is exactly the information you can no longer act on. The primary view answers what is available after planned costs, and what is coming next.

3. Local-first, with no account

   Financial data is the most sensitive category a consumer app can hold. Removing the account removes the breach surface, the sync complexity and the business model that would otherwise push toward monetising the data. It costs the convenience of effortless multi-device sync, and that trade was made deliberately.

What building it taught me that transfers to operations work

• A model that mirrors reality removes features. Once the relationships were represented properly, several planned screens became unnecessary — the same effect a good operating model has on process documentation.
• Forecasting is a data-quality problem first. A projection is only as good as the recurring items behind it, which is the personal-finance version of reporting on a CRM nobody maintains.
• Defaults are the product. What the app assumes when the person supplies nothing decides whether it is useful in week one. The same is true of routing rules and lifecycle stages.
• Constraints chosen early are cheaper than constraints discovered late. Deciding on local-first at the start removed an entire class of problems that would have been expensive to retrofit.

Scope of this page

This describes design and engineering decisions in a product I built. It makes no claims about download numbers, revenue or user outcomes, because those are not evidenced here. The product itself is public and can be examined directly.