Why I started this: the problem that made me build it

The original problem was ordinary. I could open a bank app, see a balance and still not understand what that number meant for the rest of the month.

The bank had done its job. It showed money in the account and a list of transactions. What it did not show was my own context: which payments were already spoken for, which recurring costs were approaching, how much of a category had already been used and whether recent card activity was still pending.

I did not start with a plan to build a regulated fintech. I started with the feeling that a correct balance could still be an incomplete answer.

A transaction list was not the same as a picture

Looking through individual payments told me what had happened. It did not make the pattern easy to see.

A familiar merchant could appear under an unfamiliar legal name. A recurring payment could be mixed into ordinary card activity. Transfers between my own accounts made totals look busier without representing new spending. The same category could feel normal until several small payments appeared together.

I could reconstruct the month manually, but the reconstruction became stale as soon as another transaction arrived. The work was not mathematically difficult. It was repetitive and easy to stop doing.

The first product idea was to organise that record automatically and keep the original transactions visible underneath it.

The balance ignored timing

The account balance was a snapshot. My commitments had dates.

A payment due near the end of the month affected the meaning of the balance even though it had not left yet. A pending card authorisation affected what was available even though it had not settled. Income arriving later could not be treated as if it were already in the account.

That led to the safe-to-spend idea. The product could take the latest connected information, subtract known commitments and budget reservations within a defined period, then show the result as an estimate with its inputs visible.

The important word is estimate. The app cannot know about a payment that is not in the feed or a plan that was never entered. I wanted a better explanation of the available data, not a claim that software could see the future.

Subscriptions made the problem concrete

Recurring payments are easy to recognise one at a time and difficult to remember as a group. They renew on different dates, use different merchant descriptions and can be monthly or annual.

I wanted one view that identified repeated activity while still allowing a correction. Detection cannot know whether a service has been cancelled outside the app, and a repeated merchant is not always a subscription. The useful feature is visibility with uncertainty, not an automatic verdict.

That same principle now applies to categories and budgeting estimates. The product adds structure, but the user can inspect where the structure came from.

Open banking changed what was possible

Manual entry could demonstrate the idea, but it could not keep the record current without demanding the same repetitive work from the user.

Open banking offered a regulated way for a person to approve read-only access to selected account information. The bank would continue to authenticate its customer. The product would receive balances and transactions through an authorised provider without receiving bank login credentials.

Using that infrastructure also changed the company. Account information is a regulated service. Building the connection meant working with Finexer as principal, documenting data flows, completing due diligence and registering JEMA Software Ltd as an agent.

The regulation was not an extra feature. It became part of the product architecture and the public explanation.

The idea became too broad before it became focused

Once I started building, I added other ideas that did not belong to the original problem. The product began to describe several different services at once. That made the interface harder to explain and the compliance surface wider.

Returning to the first problem helped remove work. The product is now centred on connected accounts, transaction organisation, budgets, recurring-payment visibility and spending views. The optional assistant supports that interface rather than replacing it.

Some old technical identifiers remain because changing them abruptly would create migration risk. Public names and routes can change more easily than every internal key. That is another reason the underlying problem has to be clearer than the brand around it.

What I was actually trying to build

I was not trying to create an account that holds money or a service that tells people what financial decision to make. The product does not initiate payments and is not a regulated financial adviser.

I was trying to build a more legible layer over information a person already has: balances, transactions, recurring activity and a budget they control.

The problem remains the same even as the implementation changes. A bank balance answers how much is recorded in an account at a point in time. Many people are really asking what is already committed, what changed and what the number contains. The company exists to make that second question easier to inspect, while staying honest about what the data cannot tell us.

For current service details, read the company's open banking explanation and Privacy Policy.