What we decided not to build, and why

Early product plans often become a collection of everything the software could do. A bank connection produces rich data. A modern phone supports notifications, assistants and constant interaction. It is easy to mistake technical possibility for a reason to build.

We made several deliberate exclusions from the first product. They are not hidden roadmap promises. They are boundaries around the problem the company is trying to understand.

We did not build payments

The open banking service used by the app is account information only. It reads approved account data. It cannot initiate a transfer, collect a payment or change anything in the bank account.

That boundary is partly regulatory and partly practical. A budgeting view needs reliable information about what has happened and what is known to be coming. It does not need control over the money itself.

Finexer Ltd, the authorised principal firm, offers broader infrastructure to different customers. This product does not use its payment initiation capability. JEMA Software Ltd does not hold client funds.

We did not build an account that holds money

There is no balance stored with JEMA Software Ltd and no requirement to transfer money into the app. The balances shown belong to accounts held elsewhere and are returned through a read-only connection.

Building a place to hold customer funds would be a different company, regulatory model and operational responsibility. It would not make the transaction list clearer or explain why an apparently comfortable balance already has commitments attached to it.

We did not make the assistant the product

The optional assistant is one feature. It can turn a user question and selected context into a plain-language response. It can also be incomplete or wrong.

The budgeting experience therefore has to work without a conversation. Accounts, transactions, categories, recurring payments and budget views remain ordinary interface components. A user can inspect the source information instead of relying on generated text to tell them what happened.

This is also a privacy boundary. Not every transaction needs to be included in an assistant request. Context is used when the feature requires it, rather than sending the whole account history through an AI service by default.

We did not build a public social layer

Money data is personal. The first product has no public feed of purchases, no leaderboard comparing users and no mechanism for broadcasting a budget to strangers.

Shared context can be useful in some products, but it also changes consent and audience in ways that are easy to underestimate. A transaction imported for a private budgeting view should not quietly become social content.

The absence of a social feed does not prevent a user from discussing money with people they trust. It keeps the product from making that discussion public by design.

We did not turn categories into moral scores

The app organises transactions so patterns can be read. It does not label a person as responsible or irresponsible because one category changed.

A food payment can be routine, celebratory, necessary or accidental. The transaction feed does not contain enough context to make a moral judgement. Streaks, warnings and scores can create the impression that the product knows more than it does.

The interface can show that a category moved, a payment repeated or a budget setting was exceeded. The meaning belongs to the user.

We did not ask for bank credentials

Authentication happens with the bank during the regulated open banking journey. The app does not collect or store online banking usernames, passwords or passcodes.

This is not a feature we plan to add later. It is a structural part of the connection model. A support request will not ask a user to send bank security details so someone can fix a feed.

We did not try to cover every money decision

The product provides budgeting tools and spending insights. It is not a regulated financial adviser. It does not attempt to turn account data into personal instructions about every financial choice.

That boundary affects copy as well as code. A derived number can describe what the app currently sees. It cannot promise an outcome. A category can organise transactions. It cannot decide whether a purchase was right for the person who made it.

Why saying no matters

Every additional capability creates ongoing work. It needs a user journey, accessibility, error handling, support, security review, privacy analysis, monitoring and an explanation of its limits. In a regulated service, some changes also affect the principal firm's oversight.

Removing a feature from a launch plan is not the same as solving the problem badly. It can be the more accurate response when the company does not yet have the evidence, controls or attention to operate it properly.

The current scope is connected account information, transaction organisation, budgeting views, recurring-payment visibility and an optional assistant. That is already a substantial system. The things left out make the boundary legible: read information, present it clearly, and leave control of the bank account with the bank and its customer.

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