Case study · Product

INDORIDE

A complete ride-booking ecosystem: customer app, driver app, backend infrastructure and admin controls. Designed and built end to end, by one person.

Indoride app overview
TypeProduct · live app
My roleDesign + development, solo
StackFlutter · Node.js · MongoDB
StatusLive on Google Play

The problem

People need a simple, local ride-booking experience: passengers finding drivers nearby, drivers managing their availability, and an operator keeping the whole system honest. A pretty UI alone doesn't solve that; the system behind it does.

The approach

Build the complete system, not a prototype. That meant three surfaces talking to one backend: a customer app for booking, a driver app for accepting rides and managing status, and admin functionality overseeing it all, with real authentication, real location data and a real database from day one.

The product

  • Customer experience: nearby driver discovery, ride booking, fixed and vehicle-specific pricing, booking notifications.
  • Driver experience: profiles with vehicle information, online/offline status, incoming ride requests, location tracking.
  • Admin functionality: oversight of users, drivers and bookings across the platform.
  • Authentication: email OTP login with role-based access separating customers, drivers and admins.

The engineering

The architecture is deliberately simple and honest: each layer does one job:

Flutter AppCustomer + driver · Dart
→
REST API layerEndpoints for rides, users, drivers
→
Node.js / ExpressBusiness logic + auth
→
MongoDBAtlas · users, rides, vehicles

External services plug in where needed: Google Maps for location and discovery, email/OTP providers for authentication. No secrets or credentials are exposed anywhere in this write-up, or in the client.