CASE STUDY

Kizen

From Concept to Launch and Beyond

Introduction

Today Nearpeer is an established startup serving over 19 colleges and growing. But when they approached us in 2017 in search of a development partner, they were but a nascent startup with industry know-how and innovative ideas to create better social connections between new college students. While beneficial for all incoming students, these connections are a particular boon for commuters, transfer students, online students, or students with jobs and families — all growing demographics that often have a more challenging experience finding their community. Nearpeer also offers an approachable way to connect with staff and administrators, including class-based discussions outside of traditional channels like group emails.

Scaling Up with Kizen

Introduction

Kizen is a mid-sized startup focused on elevating traditional customer relationship management (CRM) software to incorporate advanced automations and data-driven insights. We were introduced to Kizen by an ex-BRSer who worked there at the time and knew and trusted our expertise.

Problem

We originally joined Kizen in a team augmentation capacity as specialists in Node.js API development, having recently adopted Node.js to build version 2.0 of their platform. Our challenge was threefold: audit the progress Kizen had made to date on the platform update, implement a complex web authentication strategy that married v1.0 and v2.0, and leave the Kizen team with a solid set of tools and conventions for use in continued development. BRS has found great success in this approach to augmentation: audit and present feedback on an existing codebase, solve for a specific problem, and along the way build tools and processes that the existing team can continue to use down the road.

Approach

At the outset of the project, Kizen needed clarity as to whether their business requirements were technically feasible (so did we!); it was critical to come to a precise shared understanding of the project’s objectives, motivations, and technical context. After multiple rounds of technical review from our team, we drafted an approach that satisfied all business needs, and helped give the impending, potentially thorny process some much needed structure. Taking a measured, planned approach prior to development allowed our team to mitigate risk and make faster progress during development, with pauses at crucial checkpoints to demonstrate progress to the project’s stakeholders.

Solution

Our ‘measure twice, cut once’ approach paid off. On launch, users seamlessly logged in across Kizen v1.0 and Kizen v2.0. As the project wrapped, Kizen got word that we had chops on the UI side as well as API development and since the audit and authentication project had gone so well, both parties agreed to extend our involvement into UX/UI development for v2.0. For over a year subsequently, we collaborated to build complex interfaces for the application using React and friends. As the front end work progressed, we saw Kizen’s development team size grow significantly as they ramped up their team to meet an aggressive deadline , and we assumed the role of frontend team lead for around 6 months while they solidified and rearranged their in-house team to accommodate growth.

Post-Launch

Over the course of a year and a half, the Kizen development team more than quadrupled. We are proud to have played a role in Kizen approaching the point where they garnered all of the in-house technical expertise and leadership necessary to become totally self-sufficient in these newly-adopted technologies. We were able to pass the baton to their team, step down from our interim frontend leadership role, and say goodbye knowing that we had played an important role in shaping both their product and their development team.





Get an estimate.