Aloe BudgetPersonal budgeting app

Building the budgeting app that I wished existed

Aloe started with a frustration I had with money software: most products ask you to learn their system before they become useful. I wanted the opposite. I wanted to do something useful with my money immediately, then add more structure only when I was ready.

Role: Product Designer and Full Stack Developer
Type: Personal product / ongoing
Product: Web-based money mangement application
Tech Stack: Vue 3, Vite, SCSS, Node/Express and MongoDB

06.01I wanted a way to manage my money before learning how to ‘budget’

My problem with most money software wasn't that it lacked power, it was that the learning curve was just enormous.

The products I had tried usually asked me to learn a framework, create categories, understand their terminology and commit to a process before I could answer any questions I actually cared about right now.

I wasn't arguing that those methods were wrong. I was asking a different product question, what is the smallest amount of information I can ask from someone and still tell them something useful about their money?

For me, that became method zero.

Just enter today's bank balance, add the bills and expenses that must happen before the next paycheck, add your paycheck amount and delivery schedule. Then Aloe tells you how much money you have left to spend before more money arrives.

Aloe Budget calendar showing four steps: enter today's bank balance, add bills and expenses, add paycheck amount and delivery schedule, and see what is left to spend.

06.02The pay period became more useful than the month

The monthly calendar is convenient for software, but it wasn't always convenient for the way I experienced cash flow.

I've been paid every other week, the 15th and last day of the month, and I've had consulting periods where the next paycheck was uncertain. That last situation exposed the weakness of the monthly model most clearly. If I couldn't predict when money was coming in, the important question became, how long until my money ran out?

I started by putting bills on a calendar, dropping in a paycheck as soon as I could reasonably expect one, and carrying a running left-to-spend balance forward day by day.

That let me scroll ahead and see when the balance would go negative. It also made the effect of today's spending visible in the future. The calendar became more than just a way to see the days, it became a cash-flow visualization.

Aloe Budget calendar with an outlined pay period and daily left-to-spend balances, showing how spending today affects the money available in later periods.

06.03I kept adding control without making it mandatory

Aloe was designed around a simple premise, that complexity should be available when the user wants it, not compulsory before they can begin.

But there is an obvious problem that comes with an intentionally low barrier to entry, eventually some people want to do more.

For example, I wanted to reserve money for groceries or gasoline. I wanted repeating transactions to appear automatically. I wanted to remember where the money went, see patterns in past spending and eventually track more specialized things like using credit cards to earn rewards points.

I didn't want any of that to become a prerequisite for the simpler original use case. I wanted complexity to be available, not compulsory, so I started thinking about Aloe as a set of optional levels rather than one prescribed methodology.

The user can stop at method zero forever and still successfully manage their money. Or they can add more techniques one at a time, in whatever order makes sense for them.

Aloe Budget calendar showing optional expense groups for groceries and gasoline, recurring bills highlighted red when overdue, and credit-card transaction tracking.

06.04I wanted a design playground and to better understand engineers

Aloe became both a real product and a training ground, it was a place where I could iterate end-to-end and keep my engineering fluency current.

Aloe gave me something professional environments don't always provide, repeated full-cycle product practice. I could make a design decision, build it, use it, discover what was wrong, return to Figma, redesign it and then change the implementation again—without waiting months for another team or roadmap window. That created far more design-and-build repetitions than I would get from my day job or from treating a portfolio concept as a static prototype.

I had engineering experience earlier in my career, but modern web application development has changed enormously. I wanted to refresh my programming fluency instead of relying on knowledge that was years out of date. So I intentionally chose a stack similar to the technology my engineering peers were using at work and took on the full application programming myself.

That wasn't because I wanted to change careers. It was because I wanted to understand design decisions from the builder's side again. What often looks “simple” in Figma actually contains a completely different problem once someone has to make it persist, repeat, recover and scale.

And there is a larger personal reason I keep working on Aloe, I think of myself as a product person first. Design is the craft I built my career around, but the thing I care about most is creating something useful enough that people choose to keep using it.

Aloe Budget's design and development workflow, showing interface designs in Figma, Vue code in VS Code, and the working calendar app in Chrome.

06.05The calendar was where the product model became understandable

I started with ledger-style pay-period panels. Using the coded prototype convinced me that time—not the transaction list—should be the central interface.

My first working design centered on what I called a ledger: one pay period, a small strip of calendar days at the top and a large list of transactions underneath. Then I built it and started using it, and something interesting happened, I kept wanting to interact with the tiny calendar strip instead of the ledger.

The list told me what existed but the calendar told me when it mattered. I kept needing to see what I had paid in relation to today, when the next obligation was coming and how far away the next paycheck was. Every time I looked at the ledger, I found myself mentally reconstructing that timeline.

I stopped building the ledger direction and went back to Figma where I drew the calendar as the product's primary canvas. I removed the heavier left navigation, made the calendar the visual anchor and moved add/edit interactions into floating shelves so the user could stay oriented around time while working.

That design felt much better immediately.

Comparison of Aloe Budget's original pay-period ledgers and redesigned calendar, showing the shift from long transaction lists to a timeline of bills, paychecks, and daily balances.

06.06Being my own customer is a great place to start but it’s not the goal

I already knew that a product built around my own habits will not automatically work for everyone else. That is not an accidental limitation of Aloe, it is part of the project plan.

Phase one has two jobs: give me a serious product-design and engineering playground, and produce a complete-enough working model that people can react to something concrete.

I have found that people are much better at saying “this doesn't work for me because…” than answering “describe the perfect money-management system from a blank sheet of paper.”

I want phase two to begin with something real. The working prototype is not my evidence of product market fit. It is the research stimulus for finding out what other people's mental models actually are. I expect many of the people I show my work to will reject parts of my model quickly and that’s the point.

The questions I expect user testing to answer are: Which parts of method zero are broadly useful? Where does my pay-period model conflict with how someone else thinks? Do distinct money-management personas emerge? Can multiple methods really sit on top of one shared data model?

A person reviewing Aloe Budget's working calendar at a desktop computer, with a callout explaining that a real product gives users something concrete to respond to during testing.

06.07Sometimes understanding the system means building it myself

The other case studies in this portfolio happened inside organizations with product managers, engineers, researchers, executives, customers, roadmaps, legacy systems and constraints I could not fully control.

Aloe removes that distance.

If the interaction is ambiguous, I have to resolve it. If recurrence breaks the data model, I have to rethink it. If the architecture makes a simple user experience difficult, I have to decide which layer should change. If the product model doesn't survive contact with the working software, I have to go back and redesign it.

That has made Aloe an amazing laboratory for the kind of designer I already was becoming. The same pattern shows up in my professional work but here I get to carry the loop from the first product question all the way into a running application.

And that is why I keep building it. Not because I want to stop being a product designer and become an engineer. Because knowing how software is actually made—and having to live with the consequences of my own product decisions—makes me a better product designer.

Four-step design process: understand how the system really works, find the model inside the complexity, turn it into something understandable, and make it real.