What it solves
Balance Ctrl is a personal finance app I designed, built, and run at balancectrl.app.
The pain is not “missing a chart.” The pain is living like this:
- You update a spreadsheet once… and two weeks later that number is already a lie.
- You leave the store thinking “I’ll log it when I get home” — you forget, and that purchase never existed in your accounts.
- “Rent is every month” lives in your head, not as something you can see, mark paid, or anticipate.
- Nobody warns you that the card cuts today or that next week’s Xbox payment lands.
- You bought something on installments: how many payments have you made on the watch, and how many are left?
Balance Ctrl exists to take that mental load off: know where you stand, what is coming, and hear about it in time.
What the user gains
| Before | With Balance Ctrl |
|---|
| Balance is a memory or a stale spreadsheet | You see what you have from data you update when you log movements |
| Monthly bills are “I’ll remember” | Each cycle shows up as a concrete due item you can handle |
| You find out after they already charged you or cut you off | You get reminded before it slips |
| Months left on a device/credit are a mystery | You track how many are done and how many remain |
The product does not replace your bank.
It gives you an honest place to decide with up-to-date information.
How it does that (no magic)
Three simple ideas:
- Real data — balances, income, expenses, categories, and payments. If you log a spend, the balance moves with that fact.
- Recurring becomes concrete — “every month” stops being only text: the system creates this cycle’s due item so you can see it, pay it, and close it.
- Reminders outside the screen — when something is due, you can find out even if the dashboard is not open. Heavy or scheduled work runs in the background so the app does not feel stuck.
Front end: React + TypeScript.
API and data: Rails + PostgreSQL.
Same foundation for web and phone use — one product, not two worlds.
What I built
- The product experience (what the user sees and which problem each screen closes)
- The money model underneath (balances, movements, recurrings, installments)
- API, data, and reminder logic
- Shipping and running balancectrl.app
Outcome
- Live product: balancectrl.app
- Day-to-day loop: see balance → handle what is due → get reminded
- Less dependence on memory and on spreadsheets that fall behind
Summary
- The pain is uncertainty: not knowing, forgetting to log, finding out late.
- The app centers where you are and what is coming.
- Monthly and installment plans must be visible and actionable, not only a memory.
- A reminder matters if it arrives in time, not only if a badge exists in the app.
- The tech (React, Rails, Postgres, background work) serves that relief — not the other way around.