I recently decided to build a financial reporting application as a teaching aid to support professionals in different finance roles. Of course, I can easily explain things verbally and not commit to a build like this. But I have always been a big believer in the “show, don’t tell” philosophy. Besides, I prefer to use fewer words where I can.
But I had other reasons for building this app which I’d like to share.
The Why
Training on financial reporting has evolved a lot. We used to have physical ledger books that forced you to think about transactions in their entirety. While technology and software have led to efficiencies in this reporting domain, it has also had the unintended consequence of reducing the need for that level of thought.
I set out to create training material that emphasised those ideas needed to understand Financial Reporting holistically. I also needed it to be in a context that people are familiar with and recognise from their roles. That just meant the training would have to look and feel like the tools financial reporting professionals (predominantly accountants) are working with. It would have to capture both the efficiencies and the pain points of these roles while exposing the relevant ideas and exploring them in real terms.
That’s why it had to be a financial reporting application. But the decision didn’t end there.
Why not just use one of the tools that are already out there?
Well, this is an obvious question you might ask. I did sample some reporting solutions. They’re all fit for their intended purpose. Since these vendors don’t intend to train up finance professionals, it would seem unfair to assess their performance against a goal they never had.
There is though, another reason why I chose to build from the ground up. It’s summed up in one word which finance professionals are intimately familiar with:
Proprietorship
You cannot control something you do not own. I wanted to have the freedom to use this resource in any way I please and not be limited in this regard.
That’s how I decided to build. On to the next step.
To Code Or Not To Code?
The next challenge was building the app. And this brought me to another major decision: Do I code or not?
I’ve always wanted to learn a programming language and this was the perfect opportunity to do so. There was a slight problem. I needed to turn this project around in weeks, not months. And I don’t know how to code.
Having used spreadsheets extensively in my finance career I knew I’d be able to get to an outcome much quicker.
Another reason I decided to go with spreadsheets is that finance professionals are already intimately familiar with them. I reasoned this would make it a bit easier to absorb the message.
And that’s how I decided to base the app on spreadsheets (at least for the time being) rather than learning a new programming language.
Do I Use Excel or Google Sheets?
This is where things came to a head. There’s no shortage of spreadsheet apps here but two that stand head and shoulders above the rest of the pack are Microsoft’s Excel and Google’s very own, Google Sheets.
As it happens, I’m an Excel enthusiast (it’s even the subject of my most recent course) and so it would seem like the natural choice for me, pretty much for the same reason I chose to build within a spreadsheet over coding; familiarity. To be clear, both Excel and Google Sheets are extremely robust, and so I was not deciding on this basis.
But I had some other priorities to consider.
The Google ecosystem is natively cloud-based. This means they do cloud very well. Like cloud storage, cloud apps and (importantly) collaboration.
This is a priority for me going forward as I look to migrate my workflow to the cloud. Part of the reason for this shift is personal. I recently switched to a Mac device and I’m somewhat in between Windows and Mac ecosystems. Using a cloud-based solution like Google’s workplace simply means I’m not tethered to either one.
And that’s how I chose Google sheets over Microsoft Excel. Controversially, or practically? You decide.
The Build Process
This build has challenged me positively. Incidentally, it is also my most complex spreadsheet project. Suffice to say it stretched me. The first iteration was functional, yet sub-par. I was tempted on several occasions to lower my working standard. And every time I did so, I was unsatisfied with the outcome. As a result, I would raise the standard again. Some might refer to this as the “infinite loop.”
Thankfully I’ve managed to break out of it.
This was also the first time I worked with Google sheets at this level. Although my spreadsheet knowledge from Excel has carried forward, there was the occasional shortcut that didn’t work. A reminder that I’ve ventured into a different realm.
It took me about eight weeks (give or take) to complete this build from scratch. The hardest part was starting on a blank slate, conceptualising different aspects of the model and how they relate to each other to create my ideal user experience. I got through the technical hurdles by thinking through the problems, and knowing what to Google.
But it wasn’t that simple, and I often wondered whether I was too far out of my depth. That said, the main take away from this experience is that discipline and persistence still matter.
Next Steps
This journey also piqued my interest in building apps. I spent some time learning JavaScript as a result. Shoutout to the team over at Codecademy for creating a first-class learning experience on the JavaScript program I recently completed. I plan on sharing what I built here as a fully-fledged app one day. Getting familiar with a programming language (I think) is a step in that direction.
