Ride-Hailing App with Surge Pricing

Project overview

We built a ride-hailing platform for a mobility startup launching app-based taxi services in a busy metro area. Riders book a car, see the fare before confirming and track the driver on a live map; drivers go online, accept trips, navigate and watch their earnings build up in an in-app wallet.

The engagement covered product discovery, UX for both apps, the React Native mobile apps, a Node.js back end with a PostGIS spatial database, and an operations console for the dispatch team. It draws on our taxi booking app development practice and our wider on-demand mobility work.

The client and the challenge

The client had been running a phone-and-messaging dispatch desk. Operators matched rides from memory, fares were negotiated, drivers were paid weekly from spreadsheets, and at peak times riders waited without knowing whether anyone had picked up the request.

They needed automated matching that picked the genuinely nearest available driver, transparent upfront fares that could rise when demand outstripped supply, and a driver wallet that settled cash and card trips correctly — all without a large engineering team to run it afterwards.

Solution architecture & delivery

We used React Native to ship the rider and driver apps from a shared codebase of components, map screens and API clients, while keeping the two apps separate in the stores so each could have its own permissions, background location rules and release cadence.

Driver apps send location pings to the Node.js location service, which writes the latest position into PostGIS. When a rider requests a trip, the dispatch service runs a radius query for online, unassigned drivers, ranks them by estimated road distance and offers the trip to one driver at a time with a short acceptance window. A declined or expired offer moves to the next candidate, and a trip can never be held by two drivers because assignment is a single conditional database update.

Surge pricing is calculated per geofenced zone. On a short schedule a job compares open requests with available drivers inside each zone polygon and sets a multiplier within limits the operations team controls. The fare quote shown to the rider locks the multiplier at request time, so the price does not change between confirmation and pickup.

The driver wallet is a ledger rather than a balance field: every trip writes fare, commission, tips and cash collected as separate entries. Cash trips create a commission debit, card trips a credit, and payouts are batched from the net balance. The operations console shows live trips on a map, zone multipliers, driver documents awaiting approval and wallet disputes. Scaling and failover follow the patterns in our AWS architecture guide for high-traffic apps.

Key features we built

• Upfront fare estimates with the surge multiplier locked at request time
• Nearest-driver dispatch using PostGIS radius queries and sequential offers
• Live driver tracking and ETA updates on the rider's map
• Zone-based surge pricing with caps set by the operations team
• Ledger-based driver wallet covering fares, commission, tips and cash trips
• Driver onboarding with document upload and approval workflow
• SOS button and trip-sharing link for rider safety
• Operations console for live trips, zones, payouts and disputes

How we delivered it

1. Discovery. Shadowing the existing dispatch desk and interviewing drivers to capture how rides were matched, priced and paid, including cash handling and cancellations.
2. UX and prototype. Separate clickable prototypes for the rider booking flow and the driver trip flow, tested with drivers in their vehicles for one-handed use.
3. Build. Two-week sprints delivering dispatch, pricing and the wallet ledger first, with simulated drivers used to load-test matching before the apps were complete.
4. Soft launch. A limited launch with the client's existing driver pool in one area, tuning offer windows, zone boundaries and surge limits from real trip data.
5. Support. Ongoing releases, map and OS updates, and new zones added as the service expanded, much like our e-scooter rental app engagement.

Technology choices

• React Native — one team shipping two cross-platform apps with shared map, auth and trip components, plus native modules for background location.
• Node.js — event-driven services for location pings, dispatch offers and socket updates, which are many small, concurrent messages.
• PostGIS — spatial indexes for nearest-driver queries and polygon checks for surge zones, inside the same relational database as trips and the wallet ledger.

Outcomes

• Rides are matched automatically to the nearest available driver instead of by a dispatcher on the phone
• Riders see a fixed upfront fare before they confirm, including any surge
• Drivers can check their earnings, commission and cash balance at any time in the app
• Weekly spreadsheet payouts were replaced by batched payouts from the wallet ledger
• The operations team manages zones, pricing limits and driver approvals from one console
• New service areas are added by drawing zones rather than changing code

FAQ