01 · Context and goal
A taxi company in a small town was running the old way: a dispatcher taking calls, drivers on radios, records in a notebook. Aggregators were moving into the region and taking up to a third of earnings in commission. The owner wanted something of his own — a system that does everything an aggregator does but belongs to the company.
The goal: a full-fledged taxi service in four parts. Passengers book rides in the app. Drivers accept orders and see the map. An operator manages the line manually when needed. The owner sees metrics, drivers, orders and finances. And all of it works in real time.
02 · What was hard
- Real time across every role at once. Driver locations, a new order appearing, acceptance, rejection, trip status — everything has to update live for the passenger, the driver, the operator and in the admin panel at the same time. It's built on Socket.IO: one event fans out to every connected role.
- Dispatching orders between drivers. An order has to be offered to suitable drivers (by pickup zone, tariff and status), they need time to accept, and if they decline it has to move on. The system keeps a list of drivers who declined so the order isn't offered to them again. This is a separate dispatch service, not just “push to everyone.”
- Tariffs and zones. Standard and cargo rides have different prices and different highlighting. The fare is calculated from the pickup address and the city zone, not as a straight line. A RUB 1,080 cargo order and a RUB 220 standard order in the same list have to look different so drivers don't mix them up.
- Honest statuses. “Driver online” has to mean they're actually on the line right now, not “logged in two hours ago.” Stale statuses are a common pain in systems like this. We made sure the status reflects the current state, not the last known one.
- The operator as a safety net. Automation doesn't cover everything: an elderly passenger calls in, or an address is hard to find. The operator has to be able to create an order manually, assign a driver, edit or cancel it — on top of the same real-time system.
The point wasn't to “build another Uber.” It was to build a system the company runs itself and sets its own rules in — with no one else's commission.
03 · Four systems
Passenger app
Sign-in by phone number (SMS), order creation with points picked on the map and the fare shown before the ride, live car tracking. A simple interface — book a taxi in three taps.
Driver app
Go online with one button, a feed of available orders with the tariff and price on every card, a map with order pins, claiming an order, an earnings screen. Standard and cargo orders are highlighted differently. Drivers can turn on auto-assignment or accept orders manually.
Operator console
A live map of drivers and orders, manual order creation and assignment. The operator sees who's on the line and which orders are active, and can step in: create an order for a passenger who phoned in, assign a driver, cancel. The order status shows its current stage.
Admin panel
The full picture of the fleet for the owner: users, drivers (with moderation of new sign-ups), orders, tariffs, city zones, reviews, performance. The dashboard shows the key numbers — users, drivers online, orders and revenue.
04 · Results
The taxi company runs on its own system with no aggregator. Passengers order through the app, drivers accept orders in real time, the operator backs things up on tricky cases, and the owner sees the whole picture in the admin panel. Over a thousand users, more than a hundred drivers, thousands of processed orders.
All the commission stays with the company — there's no outside aggregator taking a cut. The company sets its own tariffs, zones and dispatch rules.
05 · What's next
The system keeps evolving: new tariffs, smarter order dispatch, driver performance analytics, better maps. An architecture of four systems connected through Socket.IO lets us add roles and scenarios without breaking what's already there.
The backend (Node.js + MongoDB + Redis) and the admin panel (React) run in Docker, and the mobile apps are built for iOS and Android from a shared Flutter codebase. New features ship to the server; mobile updates go out through the app stores.