Like I explained in my introduction, Building from Scratch, a challenge usually has more than meets the eye, and I think part of what makes a tech consultant, product manager, solution architect, etc. good at their job is understanding the depth of a challenge and translating that into a tangible solution.
While I had grand ambitions of more complicated products, I ended up landing on the challenge of developing a savings calculator. It's not revolutionary, and definitely not something that hasn't been done before, but it's a good opportunity to build a simple tool with a socially conscious benefit, regardless of how basic. There are companies built entirely on the idea of providing calculators such as this one. SmartAsset comes to mind, or Wealthfront and their "Path" financial planning solution.
Back to the problem at hand, how do I build a savings calculator? The end result is relatively straight forward: a user-configurable calculator that leverages a combination of assumptions and calculations to project savings amounts over time, presumably to estimate wealth pre and post retirement. Ideally the whole calculation can happen live with near-instant recalculation both in the underlying data and an accompanying chart.
To accomplish this, I'll intend to follow this rough outline:
- Have a web application perform a simple compounding calculation.
- Allow user-inputs (variables) to dynamically update underlying calculations.
- Include a time-series line chart, tracking the value over a period of time.
- Live-update the chart with new data as it becomes available.
- Increase the complexity of the formulas driving the data calculation.
- Make it user friendly (UI/ UX), and refactor for efficiency.
This is something I don't currently have experience with, although the idea sounds relatively straightforward. As new data is available (as user inputs change), rebuild the chart to include this new data. Luckily Chart.js includes out of the box animations for events like this, a vue-chartjs even includes two mixins to support reactive data. As I've seen in other demos, I foresee this making the most sense to include a short pause between a user input and when the chart is recreated to prevent scenarios (such as if a user input uses a slider) wherein the chart is attempting to regenerate hundreds of times in a fraction of second. I'll save this tidbit for when I'm further along, but felt it was worth mentioning.
At the end of the day, if the only input my calculator supports is linear compounding, then I've really not made anything remotely useful. I'm not trying to reinvent the wheel, but there's a range of questions which can help produce a more accurate, or at least realistic calculation, given all of the factors that one would expect to influence savings over time. Once I have all of the other pieces in place, I can refine the calculation to better adapt to different scenarios.
I've always been a fan of modern web design, and one of things I do well is designing elegant and functional pages. While the focus of this project is more learning and the underlying code, I would be remiss if I didn't give it a nice "coat of paint". Lastly, although the gameplan is to build everything in a scalable, adaptable fashion, I won't deny that the "first pass" of the code may not be the most efficient. Hopefully, by the end of this experiment, I'll have a base of knowledge for which I can build upon.