How to Build a Taxi App: Core Components and Architecture

What a taxi service is made of

A taxi app is not one app but a system of several parts:

• passenger app — booking, waiting, riding, paying, rating;
• driver app — going online, accepting rides, navigation, earnings;
• dispatcher and admin panel — manual bookings, monitoring, fares, drivers, disputes;
• backend — geospatial search, matching, pricing, trips, payments, notifications.

The hard part is not the screens but real time: thousands of cars constantly send positions, and a ride must be assigned within seconds.

Passenger app

Minimum feature set:

• pickup and destination selection with address suggestions and pin adjustment on the map;
• fare class choice and an upfront price before booking;
• driver search, driver and car card, live car position on the map;
• payment by cash, card or wallet balance;
• chat or calls through a masked number, a "share my trip" button;
• trip history, receipts, rating.

Driver app

• "online / offline" status and background location sharing — respecting iOS and Android background execution limits;
• incoming ride offer with an accept timer, distance to the passenger and estimated fare;
• navigation via the built-in map or external navigation apps;
• trip states: heading to pickup, arrived, in progress, completed;
• balance, commissions, payouts, documents.

Dispatcher panel

Even an automated service needs dispatchers: phone bookings, corporate clients, outages and complaints. The panel shows a map of cars and rides, lets staff assign a ride manually, change fares and zones, block drivers and resolve disputes with the full trip history.

Matching: how a ride gets assigned

1. Find available drivers near the pickup point using a geospatial index (hexagonal grids such as H3, geohash or PostGIS).
2. Filter out unsuitable ones: fare class, car type, child seat, blocks.
3. Sort by road-network arrival time, not straight-line distance — a river or a one-way street changes everything.
4. Offer the ride to one or several drivers with a timer; on decline, move to the next.

An alternative to sequential offers is batch assignment: the system collects requests for a couple of seconds and distributes them to minimise total waiting time across all passengers.

Fares and surge

The price usually consists of a base fare, per-minute and per-kilometre rates plus a minimum fare, waiting time and extras. The upfront price is calculated from the route returned by the mapping service; the final price comes from the actual track or is fixed in advance.

Surge pricing kicks in when demand in a zone exceeds supply. It is calculated per zone over short time windows. Important:

• show the multiplier to the passenger before booking;
• smooth out spikes so the price does not jump every minute;
• check how surge multipliers are regulated by local rules.

Maps and geodata

You need four functions: map display, geocoding (address to coordinates and back), routing with traffic, and ETA estimation. You can use commercial APIs or run your own routing on open data (for example, OSRM on top of OpenStreetMap). When choosing, weigh address quality in your city and the cost of requests at scale — routing calls are extremely frequent.

Payments

• Card pre-authorisation at booking and capture of the actual amount after the trip.
• Card tokenisation via a payment provider — card numbers must not be stored on your servers.
• Service commission, driver balance and regular payouts.
• Correct handling of cancellations, paid waiting and refunds.

Real time at scale

Architecture decisions to make from day one:

• Persistent connections (WebSocket or MQTT) for locations and statuses, with push notifications as a fallback.
• Driver positions live in a fast in-memory store (for example, Redis with geo commands), not in the main database on every update.
• Trip tracks go through a message queue and are saved in batches.
• A trip is a state machine with strict transitions; two drivers accepting the same ride is prevented by an atomic operation.
• Services are split by load: location and matching scale separately from billing and the admin panel.

Common mistakes

• Matching by straight-line distance, ignoring roads.
• No offline logic: the driver loses connection mid-trip and the ride gets stuck.
• No dispatcher panel at launch — every incident becomes manual database work.