Mobile app developer in Nepal
Flutter apps taken all the way to the Play Store — past 50,000 downloads — with the payments, notifications and offline behaviour that production actually demands.
Shipped, not prototyped
I'm Binit Koirala. I've been building mobile apps with Flutter since well before it was the obvious choice in Nepal, and the apps I've worked on have passed 50,000+ combined downloads on the Google Play Store.
The gap between a Flutter app that demos well and one that survives contact with real users is mostly everything that happens after the happy path. Payments that fail halfway. Notifications that arrive when the app is dead. A connection that drops mid-request on a mobile network. That's the actual work.
The parts that are genuinely hard
Payments
Payment integration is where mobile apps quietly lose money and trust. A charge can succeed on the gateway and fail to register in your app; a user will background the app mid-flow and reopen it expecting the truth. Getting this right means treating the gateway as the source of truth, reconciling on the backend rather than in the client, and making every payment operation safe to retry.
Push notifications
Notifications look trivial until you need them to be reliable. Delivery differs by platform, by OS version, and by whether the app is foregrounded, backgrounded or terminated — and aggressive battery optimisation on many Android devices will happily drop what you send. Building for that reality, instead of for the simulator, is the difference between a feature and a liability.
Networks that aren't the office WiFi
Apps used across Nepal run on connections that fluctuate constantly. That pushes you toward offline-aware state, optimistic updates that can be rolled back honestly, and retry behaviour that doesn't hammer a struggling connection. An app that degrades gracefully on a bad network feels dramatically better than one that's fast only when conditions are perfect.
Release engineering
Shipping is a skill of its own — signing, store listings, staged rollouts, and being able to push a fix quickly when something slips through. I set up release pipelines so that publishing is routine rather than a nervous afternoon.
Because I also build the Django backends these apps talk to, I can fix a problem on whichever side it actually belongs to. A surprising number of "mobile bugs" are really API-shape problems, and vice versa.
Where I've done this
- Code Himalaya — several years building and shipping Flutter apps to the Play Store, growing from developer to senior. Payment gateways, push notifications, production monitoring.
- Sangatha (formerly StretchYo) — led mobile development end to end for a US-based habit-building app: architecture, features and the release pipeline. Live on the Play Store.
- Fasto — co-founder. Quick commerce is a mobile-first product, and the ten-minute promise has to hold on the device as much as on the server.
Stack
- Core: Flutter, Dart, state management, platform channels where needed
- Services: Firebase, push notifications, analytics, crash reporting
- Integrations: payment gateways, REST APIs, deep links
- Delivery: CI/CD for mobile, Play Store releases and staged rollouts