DollarCal: Let there be forecasts

If you’ve been following along with my entries from January and February for the One Side Project Challenge, let me start by assuring you as soon as possible that what follows will not be excuses for how much I didn’t do this month!

While I didn’t spend as much time on DollarCal in March as I would have liked, I knew I couldn’t have another month like last month. After all the “user validation” I had received, I knew I needed to get back to work fulfilling this challenge.

So with that, I’m pleased to announce that both goals (and then some) I set for March were fulfilled:

• Based on the entered transactions, a current balance, and a (defaulted to 90 for now) desired amount of days to forecast, I have the calculations flowing to forecast debits and credits
• That information is then being fed to a list view that clearly displays: Date, Day, Previous Balance, New Balance, Changes, Transaction(s), Amount(s), and Type(s)
• You maybe even notice (in the below screenshot) that I’ve added DollarCal’s first user (me) requested feature: Show only days with transactions. This is likely a temporary option. It was just silly to output calendar days that weren’t transactionally active.

List view of transaction based forecasting — Amounts are fictitious and for example purposes only ;)

Your “Calendar based view of future finances” still has no calendar

Guilty. As usual you’re right.

At this point in development it’s important to me that I can clearly see information that I’m producing as easily as possible. Theres no better way to do that than by representing everything in a list.

Ideally in the future this information resides in a beautifully formatted calendar with lots of JavaScript to display transaction details on hover, intelligently highlighted points of interest, and insightful notifications that give you information you didn’t even know you were looking for.

However, while you may remember my proud claim of being “a Python guy,” that also means I’m not a JavaScript guy. Or a front end developer at all for that matter. So for now it’s Bootstrap, Jinja templates, and mostly copy & pasted HTML.

It’s not good enough yet

Obviously (maybe?). But in my last post I said that I might consider this current state the “MVP.”

Which reminded me of this cartoon. It’s funny to me that even with this products expectations being entirely my own, it takes iteration to get to a place that I’m proud to even call a minimal viable product.

It’s important to recognize how critical that iteration process is though. During development there were multiple points in time where I’d say “this should work like this, but not yet.”

Of course, feedback from others is also critical (so please leave me yours!). So, after chatting with Samantha, our colleague David, and my girlfriend on a drive back from Glendale, I’ve settled on the following next steps:

The ability to add / remove ad-hoc transactions. These are transactions that will likely only occur once. They’re typically expenses that you know are going to happen but aren’t part of your normal finances. Vacations are a good example. Some things to consider:

• Should these transactions be automatically cleaned up (deleted) after the transaction date without interaction from the user?
• Should the transaction be retained so that a user can look back at their ad-hoc spending?
• Should the user have the ability to choose that behavior?

Every X weeks transaction scheduling. In other words, accounting for the fact (as an example) that some people get paid bi-weekly. Some things to consider:

• The more flexibility I allow here, the more complex (very quickly I might add) this can get. Scheduling, or time in general in Computer Science can be incredibly difficult. Don’t believe me? Check this video out sometime.
• Do I allow people to simply change the week’s frequency?
• Do people have transactions that more closely resemble recurring calendar events (i.e. every Monday, Wednesday, and Friday)?

User Management. Ideally, DollarCal will have users some day. And while that day may still be some time from now, it’s important to introduce the concept of users into all the code written so far since everything I’ve built will have individual meaning for each user.

Not to mention, having a test account to continue displaying in screenshots with bogus amounts will allow me to have a personal account with my actual finances :). Some things to consider:

• Even thought I’m using Django and its built-in user management would be the easiest to implement, do I want to tie myself that closely to an implementation?
• Being in the business of storing login credentials is not a business I want to be in
• Would users accept only being able to use DollarCal if they had to sign up with Facebook, Google, or some other authorization provider?

These 3 things are personally what’s left for me to forever throw away my spreadsheet in favor of DollarCal.

So, these are exciting times

It’s incredibly fulfilling that with less work than originally predicted, I can already see the light at the end of the tunnel.

There’s no doubt that DollarCal will go through endless iteration after this set of proposed next steps. But getting to the point where I’m not using a spreadsheet was priority one.

Priority two is deployment and getting it in the hands of users for alpha testing. Which to me is incredibly exciting because it means I get to focus on my more recent passion, DevOps.

Admittedly I’ll need to decide in a few months where the project is at and how much time and at that point monetary resources (cause ya know, servers) I’m willing to devote to DollarCal.

Ideally I’d go full automated infrastructure-as-code provisioning with Amazon Web Services.

More likely, I’ll go with Heroku or something similar for a while.

I’d love to hear your impressions so far! Does seeing the forecasts clear up any suspicions you had about how this was going to work? Do you have suggestions on small scale web application hosting that I can start researching sooner than later?

As always, give this article a 💚 recommend if you enjoyed reading it. And please, follow One Side Project Challenge to see all the awesome things being worked on.