Behind the Global Launch: Decoding the Android Engineering Strategy for Our New App
Article Summary
Karthi from Mercari's Cross Border team reveals why they chose native Android over Flutter and React Native for their global marketplace launch. The decision wasn't about theory, it was about leveraging 10M+ downloads worth of proven infrastructure.
Mercari built a new global marketplace app serving multiple countries with a small team and aggressive timelines. They had to choose between their existing Flutter, React Native, and native Android experience. This deep dive explains the architectural decisions behind their native Jetpack Compose approach and how they're shipping one build to all markets.
Key Takeaways
- Chose native over hybrid to reuse proven libraries from 10M+ download Japan app
- Monorepo with modules-graph-assert plugin enforces strict product isolation rules
- Single global build serves all countries via BFF layer and remote config
- Switched from REST to gRPC with Wire for performance and type safety
- Maintained small team velocity by avoiding Flutter library recreation costs
Mercari shipped a global Android app faster by choosing native development to reuse existing infrastructure rather than starting fresh with cross-platform tools.
About This Article
Mercari put all its regional Android users into a single binary, which meant that any critical bug would immediately affect every market at once.
Karthi's team reduced this risk by building a configurable system using a BFF layer and remote configuration. This let them customize the app for different countries without having to create separate builds.
Using one global build cut down the work of managing multiple country versions. The team could release faster and avoid the code divergence that usually builds up across different market builds.
