Personal and business finance on one data model

A bank account, a credit card and petty cash — all three are the same person’s money, and each is tracked in a different tool. Splitting personal from business into two products does not fix that scatter, it doubles it.

The same money, three separate tools

What was tried: collecting personal and business use in a single account/transaction model without splitting the two into separate products, with recurring and scheduled transactions on top.

One core, three clients

The model held: multi-account management, budget planning, goals and reporting all ran on the same core. As load grew, event-driven parts (Redis, RabbitMQ) came in; on the client side, iOS and Android were added alongside the web, with React Native.

Not splitting personal from business

Making personal and business finance two separate products is the customary path in this space, and it has exactly one justification: the business side needs teams, roles and permissions, and the personal side does not.

The price of that split is paid in the data model. If the same person’s own account and their company’s account live in two different products, the cash flow never appears together on any screen — even though the person carrying the money is the same. Two products bring two schemas, two reporting layers and the same transaction entered twice.

The path chosen was a single account/transaction model, with the business difference living in one place only: role-based permissions. Adding a team member to an account does not change the model, it puts a permission layer over that account. In exchange, business-specific flows (accounting integrations and the like) had to sit on top rather than in the core — that is the cost that was accepted.

Recurring transactions were not bolted on

The second decision is about timing. Rent, subscriptions, salaries, instalments — most of both a personal budget and a company’s cash flow is made of regularly repeating transactions.

Putting that on top as a “reminder” feature was the easy road: the user enters the transaction by hand and the system nudges them when the date comes. In that design the future never shows up in a report — the budget only knows transactions that have already happened, while the question itself is about what is coming.

So recurring and scheduled transactions are part of the core: the transaction model itself carries the repetition rule, and reporting can read what is planned alongside what has happened.

That the event-driven parts came in only as load grew was deliberate: a queue added early brings maintenance cost without a problem to solve.

The road to the SaaS

The core became a SaaS product; subscriptions, mobile apps and business features live on the product side. Details in the portfolio.