Independent Android product · 2026
ExpenSpace
Building the expense app we actually wanted to use
My wife and I already had an app for our household expenses. I kept running into things I wanted to change. Eventually, I decided to learn Android development by building the app I wanted us to use.
- Role
- Product owner, Android developer, product decisions and release.
- Stack
- Native Android, Kotlin, Jetpack Compose and Firebase.
- Status
- Released on Google Play, used at home and still under development.
The first release
A manageable product, not an endless first version
The MVP only needed to replace the expense tracking we were already doing. Spaces became the organising idea: separate places for expenses that could be personal or shared with other people.
Personal and shared Spaces
Keep different sets of expenses separate, or contribute to the same household spending record with other members.
Expense recording
Record spending with descriptions, categories, payment methods and dates.
Shared members
Invite another person into a Space so both people can contribute to the same set of expenses.
Calendar views
Look back through spending by date instead of relying on one long transaction list.
Spending insights
Review totals and category-level spending without leaving the expense workflow.
Real distribution
Test, package and publish the native Android application through Google Play.
Where it started
An app we used, and things I wanted to change
We were already keeping track of our household expenses in another app. It did a useful job, but as a developer I felt constrained at each turn. I would run into a limitation and start thinking about how I would build that part myself.
Then the app became paid. I was happy to pay a few bucks for the convenience. Its developer needed to earn too. But the developer in me kept coming back to the same thought: I had wanted to make an app for years, and here was something my wife and I would actually use.
The obstacle was finding the time to learn. Kotlin was only the beginning. There was an entire Android ecosystem around it, and alongside my existing work that had always felt like too much to take on.
The approach
Learning Android by solving a real problem
Building something useful has always been the easiest way for me to learn unfamiliar technology. My recent experience with AI gave me enough confidence to try the same approach with Android: use it to help me learn the stack while working on a product with a real purpose.
Android took a couple of unsuccessful attempts before I found a workflow that worked for me. Once I did, I laid out the use cases, decided what belonged in the MVP and put the later ideas on a roadmap.
ExpenSpace became my own product under Aliph Marketing Studio , with me responsible for deciding what to build, implementing it and getting it released.
Building it
The screens were only part of the job
I built ExpenSpace as a native Android app using Kotlin and Jetpack Compose, with Firebase behind the shared data.
Getting the first usable version out meant learning much more than UI. I had to work through application state, shared data, authentication, testing, release packaging and Google Play publishing as part of the same project.
That wider Android ecosystem was exactly the part that had made the learning curve look intimidating in the first place.
Delivery surface
- Application Native Android with Kotlin and Jetpack Compose
- Data Firebase-backed personal and shared expense data
- Product Use cases, MVP decisions and ongoing feature roadmap
- Release Testing tracks, packaging and Google Play publishing
Technical tradeoff
Firebase was a practical decision
Firebase was a choice of convenience. I did not arrive at it through a thorough comparison of every possible backend, and I wanted to avoid spending more than I had to.
I was already learning an unfamiliar ecosystem. The useful decision at that stage was to keep the backend problem manageable and get a working version into our hands.
Shipping it
From a learning project to something we use
ExpenSpace moved through testing and public release while gradually becoming part of our own household routine.
Internal testing
The first usable builds went through Google Play testing while the core workflow was still taking shape.
Public beta
The app moved beyond internal testing with early testers using the product outside my own development environment.
Household use
My wife and I started using ExpenSpace for the original reason I built it: keeping track of our own household expenses.
Ongoing development
The released product continues to evolve as real use exposes the next problems worth solving.
The useful test
We kept using it
By September 2026, my wife and I had been using the app for about three to four months.
That mattered more to me than simply getting an Android app onto Google Play. The MVP had survived contact with the reason I built it in the first place. It had become something we were actually using.
With that foundation in place, I felt ready to return to one of the ideas that had been on our minds since we first talked about building ExpenSpace.
Planned next phase
“Could I just send it on WhatsApp?”
When we were discussing the idea, my wife described the experience she wanted most. She wanted to send a short WhatsApp message when she spent something, rather than open the app and fill out a form.
She also wanted to be able to ask how the budget was looking and get the information back in the same conversation.
This interaction is planned work and is not available in the currently released application.
The interaction we have in mind
Everyday language in. Structured expense information out.
Where it goes next
Keep solving the household problem
That is the direction for AI integration: recording and retrieving expense information through everyday messages.
It gives the next phase a specific job to do. The goal is still the household one we started with: make it easier for us to keep track of what we spend, in a way we will keep using.