Just Dunzo it!
What started out as a small WhatsApp group where you could ask to get your chores done, Dunzo today has revolutionised a new market segment in India with its hyper-local runner service.
As it started expanding to new cities, Dunzo recognised an opportunity to utilise its delivery runners to not just move materials, but people across the city as well. Lo and behold, the idea of Pillion—Dunzo’s bike taxi service—was born.
To realise Pillion, Dunzo first needed to improve the architecture of the app and revise its legacy codebase to build new products faster. With product growth came team growth, which further created the scope to streamline Dunzo’s Android engineering processes and set the stage for the organisation to flourish.
On a fundamental level, our thinking matched and that was where our partnership began. We were convinced that Obvious cared extensively about user experience and the quality of the product. Prior interactions with the team, their thoughts about software engineering processes, and references from others in the industry were also a big factor in choosing to work with Obvious.
Engagement Stage
Accomplish
Scope 01
Scoping challenges for repeatedly delivering new stable features within short turnaround timesBuild 02
Adopting streamlined engineering processes to build features iteratively and reduce maintenance costsRelease 03
Establishing a culture of continuous feature releases and best onboarding practices to ensure uninterrupted product success
Scope 01
Scoping challenges for repeatedly delivering new stable features within short turnaround times
Within a very short period of time, Dunzo had already started witnessing mainstream success. To be able to add new features in the future, it was important for the team to have a mobile architecture—and an engineering team well-versed with it—that could support their ambitions of scale.
Since many parts of the Dunzo codebase had remained the same since inception, it was facing added difficulties involving high maintenance costs, fixing bugs on time and efficiently introducing new features. To operate at scale and build Pillion, the newest bike-taxi feature, the team scoped out all possible challenges. Through paired sessions and research, the following areas were identified to be acted upon:
Reviewing and defining an architecture for quick yet sustainable growth
Reducing uncertainties to deliver new features on time
Streamlining the onboarding process for new team members to institute practices for tight delivery and development
With these goals in mind, the team set out to build Pillion in an environment insulated from the main codebase with new guidelines and well-defined internal practices. The learnings from this were to be applied to the larger codebase as well as the engineering practices within the rest of the organisation.
Build 02
Adopting streamlined engineering processes to build features iteratively and reduce maintenance costs
To solve the constraints that Dunzo had identified and to build iteratively, it was important for the team to adopt a systematic approach. This entailed writing testable code, overhauling the app architecture and validating what works at each step to prevent large-scale errors.
To do so, the engineering team tested multiple architectures and approaches before building Pillion. Mobius by Spotify was selected since it could withstand the rapidly evolving edits, adapt to new features and handle the scale at which these features operate — with clean separation of concerns. The engineering and design teams worked collaboratively to streamline the product flow for Pillion.
For code that was predictable and testable, the team adopted two main methodologies: Test Driven Development (TDD) and Functional Programming (FP). Starting off with a testable codebase helped the team maintain quality and write code that was easy to refactor, even as the system grew in complexity. Moreover, it reduced the time taken for feedback cycles while ensuring continuous delivery. Similarly, Functional Programming helped preserve the separation of pure and impure code, resulting in a system that was easier to test and maintain.
These decisions drastically reduced the maintenance costs and bugs, and increased the stability of Pillion.
Release 03
Establishing a culture of continuous feature releases and best onboarding practices
After building out a strong codebase and consequently Pillion, the next step for the team was to ensure the enhancement of both delivery and development quality.
Trunk Based Development was established as a rule of thumb to establish a culture of continuous delivery and iteration. Following this framework enabled developers to keep code in the trunk branch as much as possible, instead of creating other long-lived development branches and communicate effectively. By keeping a check on the size of branches, code reviews were easier to do and took less time. Releasing builds became painless because developers avoided merging big features near release days.
Enabling the developers and designers to work hand-in-hand allowed the team to check on the feasibility of a new feature before it was created and maximise the velocity of development. Several team retros were also conducted for faster feedback and resulting iterations between teams.
To ensure that these practices could be implemented and followed even with the growing workforce, the team introduced a regular bootcamp for new hires. These enabled existing team members to carry out the documentation that was needed for new hires to better understand the context. It also allowed them to equally contribute to all aspects of engineering.
By building a new feature that exemplified building robustly and sustainably, Dunzo was empowered to make critical decisions on time and create an uplifting culture internally.