The past 2 years have been an exciting time at Citiq Prepaid, especially for the development team. Over that period, most of our efforts have been directed towards rewriting the core system that powers the company. The decision to overhaul the original system was done in an effort to not only improve on it, but also to lay the groundwork for the company’s growth and future.
So what exactly does the system we set out to rewrite actually do? The short answer, everything. Originally written using CakePHP, the system had grown to encompass every aspect of Citiq Prepaid’s daily operations. Although it’s primary function was to securely vend prepaid tokens for our customer’s meters, over a period of 5 years it became much more.
Internally, the system was was used by our help desk agents when registering new customers, answering queries and resolving issues. For our customers, it was a tool that allowed them to manage the meters installed in their properties, giving them access to up-to-date information about their tenant’s usage through various reports amongst other administrative functions. It also facilitated online purchasing of prepaid tokens for our customer’s tenants. All this functionality offered by a single front-end, 2 servers and a single database.
Screenshot of the old system
In comparison, our “new” system currently comprises of 3 front-ends , 30 or so virtual machines housing various services and spans over multiple data centers to achieve the kind of redundancy and resiliency a system with high-availability requirements like ours has.
When I joined the company, one of my first projects was to work on the new front end. At the time, the goal was simple enough, “replicate the functionality of the old system”. For the project, we chose to build the new frontend, a single page app, using Angular 2.
The decision to go with Angular 2 over React (probably the 2 most popular Javascript frameworks at the time) was made based on which framework we thought we could get up and running with in the quickest time. After a week familiarising myself with typescript and Angular 2, I made my 1st contribution to the project.
You can’t be everything to everyone
Since the development of the old system, business requirements had changed, thus requiring a relook at how user permissions and data fetching were to be handled in the new system. While building the new aptly named “admin app”, replicating the wide range of functionality available in the old system, we started running into issues adapting the new permission system on existing data. The problem was further compounded by the fact that altering existing data was not a viable option as the old system is still used by a different aspect of the business.
We realised that a large part of the functionality in the old system, and the permissions that governed it’s access, was intended for and used by our help desk agents. Features used by tenants only made up a small part of the old system but gave us the most trouble when trying to include alongside those meant for our help centre agents. It became clear that the simplest solution was to separate the functionality altogether and build a completely new app for tenants.
Building a considerably simpler standalone tenant app also allowed us to simplify the admin app without having to worry about wrangling complex permission rules. Building a standalone tenant app also allowed us to think beyond what was currently possible and start planning new features specifically for tenants. When it came time to reimplement the features used by our property owner customers, it only made sense to build a new app specific for their use case and needs too.
New customer apps
As a team, we’re really happy the results of this decision. We’re now able to plan, implement and deploy new features for specific users without having to worry about unintended consequences for the rest of our user base.
A lesson we took away from this experience was that while making sure to cover all existing features of a system was important, it is equally important to start looking for places where we could improve on it early on. When we set out to rewrite the front-end, the plan was to reimplement what already existed, but in a new framework. Had we done this without consideration of where we could make things simpler, we would have lost the opportunity to improve on the experience of our tenant users while burdening ourselves with the certainty of an increasingly complex system as business requirements called for more types of users.
In the next post, we take a peek in the behind the scenes and go into the tech stack that makes up our backend infrastructure.
Thula Zungu
Software Developer at Citiq Prepaid
