Masareef

Last week I wrote here that my marketing said 76 banks while the code recognised 130, and that the fix was to stop writing the number by hand: a script reads the registry and regenerates the supported-banks page, so the count can only be wrong if the code is wrong.

Six days later the registry holds 413. The script did its job. The number is right in the Play listing, in both Arabic listings, and on the generated page, because all four are produced from the source.

Today I opened my own Product Hunt launch page and read this: "It recognises 130 banks and wallets." Then the press kit: 130, five times, including the Arabic ١٣٠ and a table row breaking it down as "62 Egypt, 8 Saudi Arabia, 6 UAE, 54 global" — a split that has been wrong since the registry passed 200.

So the lesson from last week was only half learned. I automated the surfaces that a script could reach and left every hand-written one to rot. A press kit is not generated. A directory listing is not generated. A launch page you filled in once is not generated, and nothing on earth will tell you it went stale, because a wrong number renders exactly like a right one.

Two things I have changed:

1. The press kit now carries the full regional split, not a four-way one that stops being true the moment a fifth region exists. If a shape can go stale silently, the shape is the bug, not the number in it.

2. The tracked Play link. While I was in the Product Hunt editor I noticed the store URL had no campaign tag on it at all — a bare listing link. Every install that page has sent since launch filed as organic and cannot be recovered. That is the more expensive of the two mistakes and I only found it because I was there fixing the first one.

If you have a product live in more than three places, the useful exercise is not checking whether your numbers are right. It is listing every surface that states a number, and marking which ones a script can reach. The rest are a manual audit you have to schedule, and mine was six days overdue.

I build Masareef, a private expense tracker for Android that reads the payment notification your bank posts on the phone and writes the transaction itself, with the app closed.

The whole pitch rests on one number: how many banks it recognises. Every store listing, every directory submission and every draft press email said 76. I wrote that number once, months ago, and copied it forward without ever looking again.

Last week I generated the list from the source instead of from memory. The registry holds 130 named institutions: 62 Egyptian, 8 Saudi, 6 Emirati, 54 global. I had been underselling the one thing that makes the app worth installing by 54 banks, in two languages, across a Play listing and four directory entries.

The fix was to stop writing the number by hand. A script reads the registry and regenerates the supported-banks page and every paste-ready store description, so the count can only be wrong now if the code is wrong.

Two other things that cost more than they should have.

Android 15 redacts the content of banking notifications. That broke the direct approach, and working around it without falling back to SMS access was the hardest part of the project. Taking the SMS permission would have been easy, and it also means read access to every message on the phone, which is exactly why a lot of people will not install an automatic tracker.

An app update unbinds the notification listener. Android drops the binding on replace and says nothing, so every user who updates silently stops capturing anything. Nothing reports itself. You find out from a support message, or you never find out.

Still early. Free with a Pro tier, Arabic and English, Android only.

If your bank is not on the list, tell me and I will add it. That is genuinely how the list got to 130.