We Built a Personal App as an Alternative to a RiseUp Subscription

Project at a glance

Original service

RiseUp for personal cash flow management

Previous subscription cost

About ILS 390 per yearOwner estimate; currency assumed to be Israeli shekels. Invoice and VAT status were not checked.

Alternative

Personal app in HebrewMoneytor data, imported history, categories, and budgets.

AI tool used in development

ClaudeContribution documented in code; no separate measurement of hours or cost.

Development period

Versions documented on October 18 and 19This does not measure the full setup time or hours worked.

New ongoing cost

Not yet calculatedData source, hosting, and maintenance should be included.

Net annual savings

Not yet verified

Migration status

App built; independence not yet provenRiseUp cancellation was planned for October 20. The refresh still includes budget synchronization from it.

1. What the previous subscription provided

RiseUp was used for personal finance: understanding what came in, what went out, which categories expenses belonged to, and what else was expected to be charged. The daily task goes beyond a list of transactions. Charges, the budget month, and upcoming payments need to be connected to provide a usable picture.

The alternative was built for personal accounts only, using a data source available through Moneytor. The idea was to create screens and rules suited to how the owner tracks money, while preserving history that had already been organized. The documented result is an app in Hebrew with transactions, categories, budgets, and a forecast. Full independence from RiseUp still requires further verification because the refresh process continues to contact it for budgets.

2. The financial starting point

The reported RiseUp cost was about 390 per year. For the current calculation, we assume the currency is Israeli shekels based on context, and identify the amount as an owner estimate. The invoice, VAT, discount, and renewal terms were not checked. The full scope of services included in the original plan has not been reconstructed here.

The difference worth checking is the additional expense created by the alternative. Moneytor, hosting, and maintenance may cost money even when the interface is built specifically for one user. If the data source would have been purchased anyway, only the incremental cost caused by the app can be counted, provided the allocation is explained. Without billing data, there is no basis to call the alternative free.

3. Why build a personal app

The ability to receive transactions from an existing source made it possible to build the working layer around them: organizing categories, rules for merchants, payments, and budgets. Instead of starting with independent bank connections, the focus could be on how the data becomes the user's everyday decisions.

A personal scope makes it possible to choose what is needed and avoid building a product for every household. Still, success requires more than a screen that displays a total: a category correction must be saved, a future payment must land in the right month, and transferring history must not double-count expenses. The alternative will be considered independent only when routine updates and budgets continue to work after access to the old service ends.

4. What needed to remain after the transition

Requirements included transactions and income, monthly summaries, editable categories, budgets, recurring charge detection, and a view of future commitments. Manual entries and an activity log were added so the user could explain a change and undo it when the action was reversible. The interface was built in Hebrew and right to left.

Equally important was distinguishing what was observed in the source from what the app inferred. Recurring charge detection is based on patterns in transactions; a forecast is not confirmation from the bank. When some information is missing, coverage should be shown and the user should be able to make corrections.

5. Tools, AI, and automation

Python handles collection and processing, SQLite stores the data, and a Next.js app with TypeScript presents the result. The displayed data comes from a processed copy stored in private storage. This means the browser interface does not need the bank data source credentials to display transactions.

Claude appears as a coding partner in the version history, including work on categories and history import. This is evidence of development assistance, but does not establish hours saved or which parts were written without revision. Rules learned from history are a separate mechanism: they apply adjustments based on past data.

There is also documentation for merchant research using Claude, but it is marked as an unreleased addition that suggests changes for review by default. It does not support a claim that the alternative already provides automated financial advice.

6. How we moved the work to the new system

The foundation was transaction synchronization, categorization, and monthly summaries. The interface, category changes, and budget editing were built on top of that. Versions documented on October 18 and 19, 2026, also add an activity log, easier category selection, and charge details. The dates describe software releases, not a measurement of total development time.

Version 1.4.0 added the transfer of history from RiseUp. The import preserves source fields and adds historical transactions or transactions that fill gaps. When a matching transaction exists in Moneytor, the mechanism links them instead of displaying two. Matching checks payment method, amount, date proximity, and merchant name similarity.

The work does not stop after the first import. Each sync checks the connection between sources again, so a transaction added later does not remain alongside its imported copy. Category knowledge was transferred too: rules are created only when there are enough examples and sufficient consistency, and an explicit user correction takes precedence. This preserves the work invested in organizing the history.

7. What ongoing use looks like

The refresh process retrieves transactions, processes them, and uploads a copy for display in the app. The user opens a month, reviews expenses and payments, and corrects a category when needed. Corrections are saved and fed back into the processing mechanism so work done in the browser does not disappear at the next update. Manual entries are handled separately to prevent duplicate counting.

If a required refresh step fails, the process stops and records a failure; it also prevents overlapping runs. At the time this story was written, the sync step still included budgets from RiseUp. Therefore, displaying data in the app today does not prove that the refresh will succeed after access to RiseUp is disconnected.

The file update date is not necessarily the date the bank data was updated. Information can be processed successfully even if the source has not yet refreshed. Ongoing checks should examine the freshness of source data and account coverage alongside the app's refresh time.

8. How to check whether the alternative is truly sufficient

Project documentation notes that version 1.4.0 was deployed on October 19. To prepare this story, the code and documentation were reviewed without logging back into the private app or displaying personal transactions. Comparison and data coverage mechanisms exist, but their existence is not evidence of a financial reconciliation tested in this review.

The decisive check should cover a defined month: compare total income and expenses, check overlapping transactions, and review payments whose charge dates have not yet arrived. After that, the system needs to be used for a period without RiseUp access. Cancellation was planned for October 20; the date access ended, billing was canceled, and behavior afterward have not yet been verified.

9. What can be said about savings

If the RiseUp charge does stop, the subscription expense that may be avoided is about ILS 390 per year, according to the estimate provided. This is an annual scenario before the cost of the alternative. It is not a claim that this amount has already been saved, and one successful day cannot be extrapolated to a full year.

Additional costs for data, hosting, ongoing AI tool use if applicable, and maintenance must be deducted from that amount. The first year should also account for building, testing, and history transfer. These have not been fully measured. Ownership of the interface and the ability to customize it are real benefits to consider, but they have not been converted into currency here.

10. What we learned and when it makes sense

The screens are the visible part of the replacement. The work that makes them trustworthy lies in handling duplicates, charge dates, categories, and missing information. Importing history helps provide context at the start, but it does not by itself remove an active connection to the previous service.

This approach suits someone who has an appropriate data source, clearly defined personal needs, and the ability to maintain the app and check its results. Someone who prefers to have another party handle connections, issues, and changes may get better value from a managed subscription. In this case, an alternative with useful capabilities was built, and the next steps to establish its value are clear: resolve the budget dependency, verify that billing has stopped, and measure a period of independent operation along with its cost.