I Wanted to Know Where My Money Was Going, So I Built My Budget

I knew how much money I earned. What I did not always know was where it went.

Of course, I could look at individual expenses. I could check a bank statement and see payments for food, bills, shopping and everything else that had happened during the month. But seeing a list of transactions and understanding my finances were not quite the same thing.

I wanted a clearer answer to a fairly ordinary question: where does most of the money I earn actually go?

There was another question behind it. I had things I wanted to save for, and I wanted to understand when I might realistically have enough money to reach those goals.

Those two questions eventually became the starting point for My Budget.

A Bank Statement Could Tell Me What Happened

There is nothing particularly difficult about seeing that money has been spent.

A transaction tells you an amount, a date and usually the business that received the money. Look through enough transactions and you can reconstruct much of the month.

What I found less obvious was the bigger picture.

A €15 purchase does not look particularly important. Neither does another €20 payment a few days later. But if many small expenses belong to the same category, their combined effect may look quite different by the end of the month.

That was the information I was more interested in.

I did not simply want a record of what I had bought. I wanted to group expenses, compare them and see which categories were taking the largest part of my income.

Once I started thinking about the problem that way, the idea was already moving away from a simple expense list.

The Interesting Part Was the Pattern

Individual transactions are very specific. Patterns are not.

If I could categorise transactions, I could start asking different questions. How much went to one category compared with another? Was a particular type of spending unusually high this month? Was the balance between income and expenses changing over time?

This was one reason categories became an important part of My Budget.

Reports and charts followed for much the same reason. I did not want them simply because finance applications are expected to contain charts. I wanted a faster way to understand information that was difficult to see when it existed only as rows of numbers.

The dashboard eventually became a summary of that idea.

Instead of opening several different parts of the application and trying to construct the picture myself, I could see income, expenses, financial health, monthly information, a six-month trend and the largest expense categories in one place.

The data had not changed. The way I could look at it had.

Saving Money Created a Different Kind of Question

Tracking expenses was only part of what I wanted.

I also wanted to save money for specific goals. And once I thought about those goals more carefully, I realised that the target amount was only one part of the problem.

Suppose I want to save a particular amount. I can write that number somewhere and call it a goal. But that does not tell me very much about how close I really am to reaching it.

I wanted to see the target, the amount already saved and the contributions made along the way.

More importantly, I wanted my savings goals to exist in the same place as the information about my income and spending.

There is an obvious relationship between them. The amount I can save does not exist independently of everything else I do with my money.

This changed the application from something that simply looked backwards at spending into something that could also help me look forwards.

Not predict the future. Personal finances are rarely that cooperative.

Just make progress easier to see.

At Some Point, the Problem Became a Database

There is an interesting moment in many small software projects when an ordinary problem starts turning into a collection of data relationships.

I needed transactions.

Transactions needed categories.

Income and expenses needed dates and amounts. Savings goals needed targets and contributions. Reports needed data from different periods. The dashboard needed to take all of that information and reduce it to something readable.

At that point, I was no longer thinking only about my finances. I was thinking about tables, relationships, forms, queries and interfaces.

My Budget became a PHP and MySQL application.

The choice was practical for the type of software I wanted to build. PHP could handle the application logic, MySQL could store the financial data, and the result could run on ordinary web hosting rather than requiring a more complicated infrastructure.

The application gradually grew around the original questions.

• Transactions allowed income and expenses to be recorded.
• Categories made those transactions easier to understand.
• Goals and contributions handled savings progress.
• Reports made it possible to look at the information from another angle.
• CSV export provided a way to take data outside the application.

None of those parts was especially unusual on its own.

Together, however, they started to answer the problem that had made me build the application in the first place.

Building Something for Yourself Is Slightly Strange

When you are building software for your own problem, you occupy two positions at once.

You are the person deciding how the application should work, but you are also the person who has to use what you decided to build.

That can be useful because there is very little distance between a product decision and its consequences. If something is awkward, unnecessary or confusing, you encounter it yourself.

It can also be misleading.

Something that makes perfect sense to the person who created the database, wrote the code and designed the interface may not be obvious to anyone else. The creator knows what every field means before the page even loads.

A new user does not.

That difference became more important once My Budget started moving beyond being something built only for my own use.

A Working Application Is Not Necessarily a Product

There is a point where adding another financial feature becomes less important than everything surrounding the software.

If an application only needs to work for me, I already know how it is configured. I know where the database is. I know what assumptions I made while writing the code. If something goes wrong, I can open the project and investigate it.

Giving the same code to another person changes the situation.

Now installation matters.

Configuration matters. Authentication matters. Error handling matters. Documentation matters. Even small pieces of interface text start carrying more responsibility because I am no longer sitting next to the person using the application.

This part of product development is easy to underestimate because it is less visible than adding a new dashboard widget or report.

A feature makes the application capable of doing something new. Product work often involves making the things it already does understandable and usable without the creator being present.

My Budget eventually became more than my personal finance application. It became a codebase that another person could install on their own hosting, use as it is, or modify for another project.

That required thinking about it differently.

Why My Budget Became Self-Hosted

Personal finance is also an interesting type of software from a data perspective.

The application can contain income, expenses, categories and savings goals. Even without connecting it directly to a bank account, that information can describe quite a lot about someone's financial life.

There are many perfectly reasonable ways to build software around this kind of data. A hosted service can remove much of the technical responsibility from the user. A mobile application may be more convenient for everyday expense tracking. Bank integrations can automate work that has to be done manually in a simpler application.

I chose a different direction for My Budget.

I made it self-hosted.

The user installs the PHP application and MySQL database on their own hosting rather than creating an account on a service operated by me.

That means more control, but it does not mean less responsibility.

For developers, freelancers, agencies or people who specifically want access to the source code, it can be much more interesting.

The same application can also become a starting point rather than an endpoint. The code can be changed, the interface can be reworked, features can be added and the project can be adapted to a different use case.

That is one of the reasons I find source-code products interesting in general. You are not only distributing the finished interface. You are distributing the material underneath it.

The Codebase Grew, but the Original Question Stayed Small

Software has a tendency to become more complicated as soon as you start answering simple questions properly.

“Where is my money going?” sounds like a small question.

Then come transactions.

Then categories.

Then monthly comparisons, reports and charts.

“Am I getting closer to my savings goal?” sounds equally simple.

Then come targets, contributions, progress and the relationship between saving and everything else happening in the budget.

After that come the things that have almost nothing to do with personal finance: authentication, configuration, installation, responsive interfaces, data export and documentation.

Eventually, the small question has become a software product.

Yet I still think the original simplicity matters.

I did not start My Budget because I thought the world needed another personal finance application. I started it because I wanted to understand something about my own money that was surprisingly difficult to see when all I had were separate numbers.

Where was most of it going? And based on that, how close was I to the things I wanted to save for?

My Budget now has a PHP codebase, a MySQL database, a dashboard, reports, goals and all the other parts required to make the application work.

But underneath all of that, it is still an attempt to answer those two questions a little more clearly.