Managercash

An Android personal-finance app with wallets, budgets, recurring transactions and saving goals. Three of us built it over a university summer: me, another developer and a graphic designer. It got far enough to be a real app with a real icon grid and real people entering real expenses into it.

• Native Android in Java, built against the Android of 2014 - the screenshots still have a KitKat status bar on them.
• Multiple wallets per user, each with its own budgets, recurring transactions and saving goals.
• Expense entry as a grid of category icons with running totals on each, so logging a spend was two taps rather than a form.
• A team of three over one university summer: me, another developer and a graphic designer.

• Icons instead of a form

  Budgeting apps die because logging a transaction is tedious. Making the primary screen a tappable grid of categories with live totals was the one product decision I would keep today.

• Bring in a designer early

  Neither of us developers could have produced the icon set or the identity. Having a designer on the team from day one is why it looks like a product rather than a student project.

• A summer-shaped scope, and no plan for after it

  We scoped the build to fit a summer, which was sensible, and gave no thought at all to what happened when term started. That omission is what ended it.

Nothing broke. No architecture collapsed, no bug beat us. Final year started, the funding ran out, and we simply stopped. Almost nothing dies of a technical problem - it dies because the people building it run out of time or money. If you are about to start something with friends, that is the risk worth planning for, not the tech stack.