How Techparser Built a Ride-Hailing Operations Console on React and Firebase

The problem

A ride-hailing platform needed one console for riders, driver onboarding, rides, driver earnings and commission, payments, vehicle tiers, pricing and support tickets. Operators had to change fares, onboard drivers and answer tickets without an engineer for each change. Techparser built it as a client-side React app talking directly to Firebase, with no backend of its own, so all data shaping happens in the browser. The Firestore data had evolved over time, with older and newer field and collection names side by side, and the console had to read both.

Fares, commission and what each driver is owed have to be traceable from the ride to the payment, or drivers cannot be settled correctly. A console that breaks on older records leaves operators blind to part of their own history. Both the money trail and backward compatibility had to hold in the browser, without a server to lean on.

What Techparser built

• Every earning and payment row is joined in memory to its ride, rider and driver, with earning rows carrying the payment that settled them, so any figure can be traced back; the joins run in the browser over whole collections, which suits an operations console.
• Gross fare, platform commission and the amount payable to each driver are computed per driver and in total from the earning records, rather than stored as separate figures that could drift.
• Payments can be filtered and searched but never changed, and there is no automated payout path, so moving money stays a deliberate, separate step.
• When a ride has no stored duration, the console derives it from the first and last entries in the ride's status history instead of showing nothing.
• A single normalisation layer maps about twenty older field names to their current ones and falls back to older collection names when the current one is empty, so every screen reads one consistent shape.
• Base fare, per-kilometre and per-minute rates are edited per vehicle tier by an operator, tiers are switched on or off without a deploy, and commission and surge settings sit alongside, read-only.
• New admin accounts are created from inside the panel through a separate authentication instance, so adding someone never signs out the person doing it; the first account becomes the super admin, and only a super admin can add others.
• If the database refuses access, the console switches to a local demo dataset and says so, with every edit working the same way against either source.

Decisions that mattered

Outcome

The console is built and available for deployment. It gives operators one place to manage riders, driver onboarding, rides, earnings and commission, payments, vehicle tiers, pricing and support tickets, as a client-side React app talking directly to Firebase.

Because every figure is computed from the earning records and traced to its payment, driver settlement stays reconcilable without a separate accounting system. The normalisation layer means the console keeps reading history even as the data model changes, and pricing can be retuned per vehicle tier without a deploy. When the database is out of reach, the same screens run against a local demo dataset, so the panel can be shown or onboarded without live credentials.

Questions about this project

What technology stack does the Ride-hailing admin panel use?

The console is a client-side React application built with TypeScript and bundled by Vite. It talks directly to Firebase, using Firebase Authentication for admin sign-in and Firestore for all data, with no backend of its own. Because there is no server, the data shaping, the joins between earnings, payments and rides, and all the reporting happen in the browser over the Firestore collections.

How does the panel show reliable numbers with no backend and a schema that changed over time?

Two decisions carry it. A single normalisation layer maps about twenty older field names to their current ones and falls back to older collection names, so every screen reads one shape. And rather than store earnings figures that could drift, the console computes commission and each driver's payable from the earning records in the browser and joins every earning to the payment that settled it, keeping the numbers traceable.

Can Techparser build a ride-hailing operations console like this for us?

Yes. Techparser built this panel end to end: driver and rider management, a traceable earnings and commission model, read-only payment monitoring, per-tier pricing, admin roles and a demo-data fallback, all on React and Firebase with no backend to maintain. The same approach fits any operations console that has to stay reconcilable and read a data model that keeps evolving. Book a call to discuss what you need built.