At Praxium Labs we build this for Nepali businesses every month; this is the field-tested version. Building a competitive ride-sharing app for Nepal is an order of magnitude harder than building a competitive e-commerce app — the operational complexity is the differentiator, not the code. This is a technical scoping post; the business case is its own project.
The four apps you need
- Rider mobile app (Android + iOS): book, track, pay, rate
- Driver mobile app (Android primarily): accept rides, navigate, collect, end
- Ops / dispatch dashboard (web): monitor live, handle exceptions
- Admin / business dashboard (web): drivers, customers, billing, reporting
Tech stack
- Mobile: Flutter (single codebase, well-supported in Nepali talent market). Alternatives: React Native, native Kotlin + Swift for ultimate performance
- Maps: Google Maps (now reasonable Nepali coverage including OSM-augmented routing) or Mapbox (cheaper at scale, similar quality). OpenStreetMap is the underlying data either way
- Real-time location and dispatch: Firebase Firestore + Cloud Functions for early scale; PowerSync / Supabase Realtime / custom WebSocket + Redis for serious scale
- Backend: Node.js / TypeScript or Go. Python works but loses on concurrency for high-volume realtime
- Database: Postgres for transactional data; Redis for live driver positions and dispatch matching
- Payment: eSewa, Khalti, Fonepay, plus cash. Tip handling at end of ride
- Notifications: Firebase Cloud Messaging for both apps
- Hosting: AWS Mumbai or DigitalOcean Singapore — latency to Nepal matters
Dispatch algorithm
The core: when a rider requests, find the nearest available driver and offer them the ride. Simple in theory; in practice you handle: driver may decline (give next driver), surge pricing, predicted demand routing, anti-cherry-picking (drivers gaming the system), Kathmandu-specific shortcuts (one-ways, bike-friendly routes). Off-the-shelf "dispatch as a service" platforms exist (Hyperlane, Trafi-Plus) but most successful Nepali operators build custom. For related context, see our Building a Food Delivery App for Nepal: Architecture & Lessons post.
Realtime challenges
- Live driver position: push to backend every 5-10 seconds. Aggregate; do not store every ping forever
- Live ride tracking for rider: WebSocket or Firebase Firestore listener
- Network instability: Kathmandu cellular drops for seconds at a time. Apps must reconnect transparently and resume
- Battery: driver app runs all day; aggressive location use drains battery. Use Android Foreground Service correctly and rest-when-idle algorithms
Cost realities
- MVP build: NPR 50-150 lakh over 6-12 months for a focused product. Pathao-quality takes 2-3 years and crores
- Map costs: Google Maps free tier covers small operators ($200 free credit/month); above 50k MAU expect NPR 30-100k/month
- Infra: NPR 50,000-2 lakh/month at MVP scale; grows with active drivers and rides
- Customer-acquisition cost in Nepal: NPR 50-300 per active rider; higher for drivers (rebate / onboarding cost)
- Unit economics: typically negative for first 12-24 months; competitors subsidise heavily
Frequently asked questions
Should I build vs partner with an existing platform?
Build only if you have a thesis the incumbents are not addressing (specific geography, specific vehicle type, B2B fleet management). For pure consumer ride-share against Pathao / inDriver, partnership / white-label is a more realistic strategy.
What about regulatory side?
Nepal's ride-share regulatory regime evolved through 2021-2023; current state requires registered vehicles and driver agreements. Engage transport-licensing legal counsel early.
Can I start with just a website?
No — riders need real-time tracking and drivers need GPS + foreground location, both of which require native apps. Some niche segments (corporate fleet) can do without driver app, just dispatcher web.
How long until the app is production-grade?
6 months for a working pilot in one city, 12-18 months for scaled production with sustainable unit economics. Unit economics typically lag the product by another 6-12 months.
What's the most under-estimated cost?
Support and operations — drivers need a hotline 24/7, riders need refunds and dispute resolution. Plan ~20-30% of engineering team size for ops in early scaling.
Who can build this in Nepal?
Praxium Labs — Nepal's AI and automation consultancy, based in Lalitpur — designs and builds the systems described in this guide for Nepali businesses and for international teams hiring from Nepal. Start a project or see all services.