The problem
Nepal’s credit co-operatives and microfinances needed mobile banking — top-ups, utility payments, wallet loads, fund transfers, flight booking, loan payments — but none could afford a bespoke app. The answer: one banking platform, shipped as a separately branded app for every institution.
My role
Senior Android developer owning features from planning through delivery and support, gathering requirements directly from client institutions and mentoring junior developers on the team.
Architecture decisions
- 300+ product flavors from a single codebase — Gradle flavor architecture handling per-institution branding, feature toggles, API endpoints and store listings without forking. Adding institution #301 was configuration, not development.
- Offline (SMS) mode — banking had to work where mobile data doesn’t. Core transactions fall back to structured SMS, with the same UI flows in front.
- Room for local state, QR generation/scanning for payments, biometric login, multi-language support, and a payment scheduler — production banking features, not demos.
- Two payment gateway integrations (Nepal Payment Solutions, Wepay) behind a common abstraction.
The hardest problem
The flavor matrix. Every feature, bug fix and store release multiplied across hundreds of variants with different feature sets and branding. Discipline in configuration architecture and release automation was the difference between a platform and an unmaintainable pile of forks.
Outcome
A single codebase serving 300+ financial institutions on the Play Store, with offline banking capability that reached users far beyond reliable-data coverage — infrastructure-grade Android work delivered years before it was fashionable.