Building Budgeteer - Lessons and Experiences

With less than a semester left of college, and a need to build something I realized I needed a budget app. I knew of course about Mint, and later learned of Clarity Money far into development, but I wanted something smaller and more focused without all the extra heft that Mint provides, or the advertising and recommendations that Clarity Money includes.

Budgeteer was born (My sister came up with the name at dinner when I was home on vacation, I am not that creative). This is the story of how I built it, lessons learned, and experience gained. It’s not finished, and still requires a fair amount of work left, but not so much that I couldn’t finish in a couple of weeks if I really wanted to, or couple of months if I want to relax with it. Please feel free to check it out and leave any comments you have here (Please just avoid adding or removing too many accounts in the settings page as it does update the DB and I don’t want to check one day and see 50 linked accounts that I have to remove). Design advice is particularly welcome.

Why another budgeting app you ask. While banks and credit cards provide a lot of the same statistical information, few companies aggregate all of it together. Most people I figure have at least 2 credit cards, a savings account, a checking account, and a retirement account. Thats a lot of accounts to keep track of and the data from each individual account is useless without being combined with the others. This is the why for Budgeteer.

The Stack

MERN. MongoDB, ExpressJS, ReactJS and NodeJS. Its awesome and powerful.

In addition to these, I use Mongoose, PassportJS, Webpack , date-fns (awesome date library — very modular = tiny size), Plaid, ReactRouter, Recharts, and a few others.

Why am I sharing all the tech I used? Cause I doubt someone else wants to go through it and rebuild exactly the same product. And frankly if they do and can do it better, then go for it. I’m a free market kind of guy. I may try and bring this to market and sell it as a subscription (Plaid is the only big cost if I were to sell it as a service) but with a developer account, I am happy to be the only user and can do so for free.

Scope

Defining the scope of this project was an evolutionary process. First I focused on a desktop site. Then I wanted it to also be mobile friendly and look great on a phone with a screen as small as 4". Then I decided to build it as a Progressive Web App both as a means to learn what PWAs entail and because I think PWAs will be far more popular in the near future. With one codebase I can hit every device and get native app functionality.

The core of this product revolved around getting data from banks. Was I to resign to picking a few banks (aka the ones I use) and go through their API documentation (if it even existed) which was bound to be terrible or was there a better way. Enter Plaid, an awesome API that lets developers let users link bank accounts and access transactional information among many other data points. But for me, I got TRANSACTION DATA. The only data I needed, beautifully formatted and organized. If you ever need to work with bank accounts for whatever reason, check them out.

Core Functionality

Above all I wanted simplicity, an elegant design, and a tool that would in the end be helpful and not just a shallow clone. No advertising, no weird partnerships, no financial products recommendation, no nothing. Just an honest, quality product that I would want to use. I hope you will too. I’ve listed below the core functionality.

• View and search transaction data across all accounts
• Provide meaningful feedback that helps users understand their spending patterns — visualized statistics with charts
• Easily view your Net Worth
• Track monthly recurring expenses like Netflix, Spotify, HBO NOW, etc
• Easily add or remove accounts without any fuss or hoop jumping

Transactions

Being able to view all your transactions across all your accounts gives users the power to see in one place where they spend their money, where they can cut back, and make tackling a tough subject easier. Being able to search transactions and filter by category, date, and account type makes tracking various expenses easy. Knowing what you’ve spent in the past week in the chart keeps you honest about how you’re doing in the short term while the statistics sections help focus your attention on the medium and long term. (NOTE: The calendar button doesn’t do anything yet. Still trying to find a good calendar drop in that I can use — suggestions welcome).

Statistics

This required a charting library. I first started with ChartJS and after sticking with it for a while, I eventually switched to Recharts. ChartJS styling and option configuration is weird. Mentally picturing how something should look after an edit frequently failed to match the reality. Recharts, though more complex at first, was far easier to configure and style. The five charts I create are explained below

• Categorical breakdown of spending as a doughnut chart
• Annual spending by month for the past year with a line for the average amount per month
• Monthly Budget chart showing amount spent so far in the current month and the amount remaining
• Week vs Weekend spending to better understand if your spending changes drastically during one or the other
• Heat map showing transactions in various locations with hotter regions indicative of more spent (IN PROGRESS — Not in the demo).

Each of these charts answers valuable financial questions. Where is my money going? How am I spending it? Where can I cut back? Am I on track with my Budget? Is my spending consistent month to month? Where physically am I spending the most? Each of these charts and graphs offers a quick snapshot of a different perspective on a user’s financial health without overwhelming them with extraneous information. It crystallizes the rough idea people keep mentally remember by showing them the hard numbers of their finances. Above all, each chart is insightful and simple.

Net Worth and Recurring Payments

Net Worth quickly allows people to view their total account balances and know how much cash they have on hand in their various accounts whether it be an emergency fund they set up or their primary checking account. Showing each account gives users the transparency they need to ensure they can allocate their money effectively instead of roughly tracking amounts in their head.

Recurring transactions give users a good sense of the products and services they pay for monthly. Maybe that Pandora subscription you forgot about isn’t necessary anymore now that you started using Spotify or since you stopped using it entirely.

Settings Page

The settings page is all about bringing even more transparency to the user. They can easily remove any accounts they would rather not have linked and see if they are missing anything. Once they click remove the access tokens stored in the database are deleted and more importantly invalidated so even if someone got them they wouldn’t work.

Design

Designing Budgeteer was the most interesting part of this project. I have gone through so many iterations of finding the right way to display transactions, show the charts, style the nav bar etc. I’ve checked-out different commits across the history so you can see the progress below.

Transactions Page

3 Different Versions of the Transactions Page

The difference is stark. Transactions are far more elegant and take up much less space while communicating nearly double the information. The graph adds a visual perspective which breaks up the UI and provides the user with another quick summary of their spending trends. All the sorting options were compacted into smaller expandable parts reducing clutter and adding much needed visual breaks. It makes the design mobile friendly and easy to navigate.

Statistics Page

At first I started with a tab based design. I thought that looked cool on desktop but knew it wouldn’t scale on mobile. Then I decided to have a slider like option with next and previous buttons which the user could press to change graphs. While it doesn’t look awesome on desktop yet, it does on mobile. Maybe next I’ll switch to having a little menu bar on the bottom with an icon for each graph. That would take up the extra visual space on a computer while still also fitting on mobile. Desktop could contain words if they fit, switch to icons with a breakpoint when they don’t, and stay that way for mobile.

The Nav Bar

Oh boy. The Nav Bar. Easy on desktop but a lot of iterations on mobile. The three main ones are below. The biggest difference in the final version is in the nice little bump at the end which makes it feel more dynamic and interactive. Whether this remains the final version or I go with a more native app feel of leaving the left side attached is yet to be determined.

— UPDATE — I went with a native mobile navbar. View the site on your phone or make the window smaller on desktop to see how it looks.

Broader Comments on Design

In some of the images you might notice the font is a little thicker. I switched at some point from a 400 weight (normal) to a 300 weight (just a little thinner) and the difference was astounding. It created so much space I was amazed. Everything felt modern, cleaner and just looked better. Another idea I had was to make the color of the price in a transaction red or green based on if it was a payment or a return.

Further, using larger font sizes for the transaction name and a smaller one for the account name below it, focuses the users attention to the more important information. These and many other tricks I learned by spending time on other websites and apps just looking.

Taking a moment to notice just how an animation of a menu bar in an app looks, seeing where your eye is drawn to on a page and why, or by looking at how color is used to convey information gave me a lot of inspiration for what good design and UX entails.

Lastly, absolutely check out https://medium.muz.li/ for awesome designs and trends. This was my first go to when I felt stuck or needed quick inspiration. The designers behind their submissions are seriously talented.

Developing as a Progressive Web App

One of the most interesting parts of this project has been working to build it as a Progressive Web App. This allows it to be installed and function like a native app. The primary benefits are push notifications, setting up offline functionality and cacheing resources locally to reduce network requests. This means that with one codebase I get a site for desktop and mobile as well as native app like functionality. PWAs are kind of weird though. I have had some problems cacheing resources from a CDN with a different domain, a CORS issue I know, properly configuring a service worker, setting up push notifications, and figuring out how to get the install pop up to appear automatically. Also testing it is always difficult since it caches everything but updates to the code may not always invalidate the now stale cache.

While React Native would have let me actually build a native app, this lets users choose exactly how they want to use this product whether it be infrequently on their computers, a few times a week on their phone’s browser, or as often they use other apps. The PWA version isn’t pushed as I’m still working out the kinks of cacheing and push notifications but I hope to finish this part next and then tackle final design issues followed by any functionality I’ve put off *ahem, sorting transactions *cough, by date *cough, ahem, clears throat.

Conclusion

I’ve learned a tremendous amount about design and building a product. From tooling, to API integrations this has been one of the most rewarding projects I’ve taken up. When bored at school or when I wanted to procrastinate HW I would work on this and working on it was so much fun.

As a final thought I’ll ask you all to please leave a comment if you think a light theme would be better than the current dark theme. This has been an ongoing debate with my sister.