Martin Strobel

Husband, Software Developer, Cyclist

Baronial Design Goals

Baronial and related libraries are budgeting tools that I’ve spent the last few years working on in my spare time.

Why build your own thing at all?

A few years ago my wife and I were out hiking in Saguaro National Park. The topic of conversation was spending. We were on a budgeting haitus, and both feeling frustated that we didn’t have focus on what our financial status and goals were. We knew we were doing okay, and not at risk in the bigger picture, but smaller things caused controversey. Questions like: “where can we afford to go on vacation?", “are we eating out too often?", and “who spends more on lunches?” caused pretty real strife.

We had tried several approaches I had slapped together in the past. Largely they were using Excel or even Access, but each had their downside. Splitting transactions was always needlessy time consuming, keeping changes in sync was flakey, and other papercuts constantly begged for a more mature solution.

The year before, we had tried Mint and really given it a good whack. But I couldn’t stand how frustrating it was to find transactions it had miscategorized; or how often its estimates were just completely wrong because a large proportion of transactions had happened at a big box store and included clothes, groceries, games, dog stuff, and who know what else. Some options like You Need a Budget seemed really great, but just cost more than I thought it needed to if I was putting in all the time to allocate funds.

So what features does this thing you’re building need?

Honestly, it’ll probably never be “done” and there will always be more features to add. But the minimum requirements were pretty easy:

  • It can’t be tied to a particular budgeting ideology. It needs to be flexible enough to build whatever flow you want on top of it.
  • There needs to be a truly useful free option. The people who are most at financial risk are the ones who should least be paying for a tool to help them navigate their expenses. There may be an option to pay to make it more convenient, but it should never gouge people.
  • It must support having multiple currencies at once. A lot of my friends are from Europe, Asia, and South America. Many of them have accounts with their home currency and United States Dollars. It shouldn’t be impossible for them to use this tool just because their finances are a bit more complicated.
  • It needs to be private and secure. Some projects and companies make money by selling data about their users. This one will absolutely not be one of those. Likewise, people using this project should have absolute confidence that the best security practices are in place to protect them.
  • People should be able to build their own tools on top of it. Just because I don’t want to impose my financial philosophies on people, doesn’t mean I don’t want it to easy and streamlined for folks with a particular ideology.

Where do you start?

While there were a lot of big ideas swirling around in my head about the financial tool empire this will someday turn into, every programming project starts with a single new file. Ultimately, I chose to start by writing a command line application that can handle very simple data input and recall.

Because I’m a software developer by trade, I spend a lot of time with what I feel is a very similar task to budgeting: managing source code. Both problems are sensitive to any detail getting out of sync, both will often be the product of several people who are collaborating, and both can be reasoned about as the culmination of many changes over time.

Since 2005, Git has far-and-away been the dominant source control tool; but there have been others. There are some pretty major differences between the way different options work (probably a blog topic for another day.) But I decided to model my tool off of of Git for the following reasons:

  1. Even when using Git with multiple people, you don’t need a server.
  2. Git’s data-model makes it really easy to store different amounts of history on different devices.
  3. There is a robust ecosystem of tooling around Git, demonstrating the principle that the command-line can be the engine, and graphical tools can be built on-top of it.

So why not just build my tool as a utility on top of Git? Honestly, after having worked on it this long, I now believe I probably should have just had my tool be a wrapper over top of Git. It would have put me years ahead in the development cycle, and only added a dependency on one fairly ubiqitous tool. But at the time, I really wanted to avoid having any runtime depdencies, so that my tool could be distributed as a single binary executable. I think I’ve achieved that, but it’s been at a high-price. Hopefully, that will pay dividends and it will be easier for people who are not software developers to install.

How far along is the tool now?

At time of writing, Baronial is still in preview at version 0.2.0. One is able to log transactions in any currency (or exchanging any stock), and one is able to replay transactions. Replaying transactions can be done generally, or filtered to only show the set that impacted a particular budget or account. Transactions can be split, and include several pieces useful metadata.

What comes next?

Someday, I’d like there to be a website that can connect to banks and read transactions. I’d like there to be clients for every device. I’d like there to be flow different options for different people. Some clients may treat transactions like emails, with some getting automatically identified and processed before ever hitting an inbox. Other clients will be more like Mint, and mostly serve to recap what has happened, not project what will happen in the next month.

Right now, I’m just focusing on improving that command-line engine. I’d like it to add a command which gets and sets the values different stocks, and exchange rates for different currencies. Then tie those values into how baronial displays balances. Another high-priority feature is the ability to transfer transaction data between different machines.

If you have other ideas, please file an issue at