Context
"MTU NA PESA" means a person with money. The name is the whole thesis: plenty of people here earn — a salary, a side hustle, a small business — but very few have a clear picture of where the money goes between payday and the end of the month. The gap is not income. It is visibility and discipline.
Most personal finance apps assume a Western financial life: a single bank account, card transactions that auto-import, a credit score to optimise. None of that matches a Dar es Salaam reality where income arrives in cash and mobile money, expenses are dozens of small daily transactions, and "the budget" lives in someone's head or not at all. The existing tools were either too complex, too foreign, or both.
I built MTU NA PESA to be the opposite: simple enough that someone will actually open it every day, and structured enough that opening it every day builds a habit. The product is not trying to be a bank. It is trying to be a mirror.
The problem is not that people don't earn. It's that they can't see where it goes. Give them the picture, and the discipline follows.
Decisions
01
Decision
Design for daily entry, not monthly reconciliation.
The app lives or dies on whether someone logs a 2,000-shilling expense in the five seconds after they spend it. So the entire interaction is built around that moment — fast capture, minimal taps, sensible defaults — rather than around end-of-month reports that nobody fills in retroactively. Habit first, analytics second.
02
Decision
Income management as a first-class feature, not an afterthought.
Western budgeting apps treat income as a single number at the top of the screen. Here, income is irregular and multi-source — salary, hustle, family support, business takings. The app models several income streams explicitly, because budgeting honestly requires knowing not just how much comes in, but how reliably and from where.
03
Decision
Budget allocation people can feel, not just configure.
Allocation is framed as deciding in advance where money should go, then watching reality move against that plan in real time. The point is the small, daily feedback — you have used 80% of this category — that changes a decision before the money is gone, instead of a post-mortem after it already is.
04
Decision
React Native, so it ships and stays maintainable.
One codebase, TypeScript end to end, consistent with the rest of how Saby builds. That discipline is why a solo-built product could ship to the Play Store and keep getting updates rather than stalling after launch.
Outcome
MTU NA PESA is live on Google Play and in the hands of real users building real habits. As a founder product, it does two jobs at once: it helps people, and it teaches us — every confusing screen and every drop-off is a lesson that feeds back into how Saby designs consumer software for this market.
Live
On Google Play
Multi
Income streams modelled
Daily
The habit it builds
Replace these with your verified store figures — installs, active users, ratings — when you're ready to make outcome claims you can stand behind publicly.
- React Native
- TypeScript
- Node
- PostgreSQL
What I’d do differently
-
I would have added mobile-money import sooner. Manual entry builds discipline, but it is also the biggest source of drop-off. A way to pull M-Pesa and Tigo Pesa history — even semi-manually — would remove the single largest reason people stop logging.
-
The onboarding asked for too much, too early. Early versions wanted users to set up full budgets before they could feel any value. The right shape is to let someone log one expense and see something useful immediately, then introduce budgeting once the habit exists.
-
I should have instrumented behaviour from day one. We launched with too little visibility into where people actually got stuck. Analytics on the first-week funnel should have been part of v1, not a thing we added once we started asking why retention looked the way it did.