Content Based Web App For Quintype

A Content Management System, in essence, is a single tool that simplifies content management and marketing. It was important to keep this goal in mind while designing the overall look and feel of the tool. The goal of the development team was clear; to build a website showing stories of specific genre in the Frontend using the API that was provided by the platform. The project was identified as a brownfield project that had been going on for the past three years and was handed over to us to take it to the next level.

Since the project did exist in a certain state before we put our hands on it, the tech stack was predetermined. React was the technology for the Frontend, the project was continued in & Redux was used for State Management.

The first step was to get on call with the client, gather as much in-depth knowledge on the requirements of the product as possible and create ballpark estimates based on the inputs of the client. After multiple iterations and alterations to suit the client's needs, the in-house design team would take the requirements and prepare different versions of the designs for the client. Once picked and approved, tickets would be created for the same and handed over to the development team.

The tech team took all the requirements and planned them based on features and their priorities. Top priority was given to the bugs that existed in the product and their fixes were developed first. These fixes were delivered to the client on a weekly basis and post-approval, the project would move forward with the development and addition of new features in the mix.

The very first feature that was introduced in the product was a subscription flow. With this, users are given the ability to subscribe to paid stories. To implement this, a little research revealed an API called Accesstype that provides the functions required to implement this feature. Based on the user's active plan, visibility of a paywall and a CTA or the active story can be managed and monitored. The next feature in line was the notification module. This would notify users whenever a new story is published. Google's Firebase was used to manage notifications in real-time. A cloud function would fire an update in the DB with the new story, that would notify the users whenever a new story is published. Similarly, a watch list feature was implemented using Firebase as well, that let users save stories and sticks against their ID and retrieve them at will. Towards the end, as the project was heading into a new direction, a new login page was also implemented with a better Log in & Sign up flow.

After every implementation, the QA team would validate Happy Path scenarios with the development team locally. These changes would then be pushed to the staging and beta environment, where the QA engineer would test all the negative and edge cases. The Business Analyst was also a part of the testing process to ensure all scenarios have been covered and the application is user ready. Once all the scenarios were tested, a demo would be delivered to client and they would involve themselves in UAT on the staging server from their end as well. Post their confirmation, we would deploy the feature onto production.