Modularizing Our Driver App for Android: The Need (Part-1)
Article Summary
Gojek's Android driver app was drowning: 30-minute CI builds, 10-minute local builds, and a team that had outgrown its monolithic codebase. Something had to give.
The Gojek engineering team shares why they embarked on a massive modularization effort for their driver app. This is Part 1 of their journey from a single monolithic module to a structured, team-owned architecture.
Key Takeaways
- Build times ballooned to 30 minutes on CI and 10-15 minutes locally
- Growth from a small team to 3 clusters with multiple pods
- No clear code ownership or feature-level crash tracking was possible
- Modularization promised faster builds, enforced separation of concerns, and team metrics
- Leadership buy-in required pitching stability, health, and maintainability metrics
Gojek modularized their driver app to cut build times by 33%, reduce test feedback loops by 80%, and enable feature-level tracking of crashes, ANRs, and binary size.
About This Article
Gojek's monolithic codebase made it hard to enforce clean architecture principles. Developers kept violating the separation between API and implementation layers, even after the team adopted clean architecture patterns.
Ashish Pathak's team broke the codebase into modules with clear boundaries and interfaces. This let different teams own specific modules and try out their own architecture approaches without breaking anything else.
Gojek could now track metrics at the feature level. They measured and set budgets for binary size, crashes, ANRs, and test coverage per feature. Code reviewers were assigned automatically based on who owned each module.