Rider app, driver app, admin dashboard: what each one does

A ride-hailing platform is three products: the rider app, the driver app and the admin dashboard. Behind them is a fourth part nobody sees, the engine that matches rides and moves money. If you are planning one, you need to know what each part is for, because you are paying for all four.

What does the rider app have to do?

One thing, quickly: get someone a ride.

• Sign up with a phone number and a code.
• Set the pickup and the destination.
• See the price before confirming.
• Watch the driver arrive on a map, with his name, photo and plate.
• Pay, then rate the trip.

That's the whole first version. Founders love adding to this app because it's the one they'll show their friends. Resist it. A rider wants to be collected, not entertained.

What does the driver app have to do?

More than you'd think, and it matters more.

The driver signs up and uploads his documents. Once approved, he goes online. A job comes in with the pickup, the distance and the fare, and he has a few seconds to accept. Then navigation, start trip, end trip, and what he earned.

He also needs to see his money clearly. What he made today. What he owes in commission. When he gets paid. A driver who doesn't trust the numbers leaves, and without drivers you have a rider app that says no cars available.

This app runs all day on a mid-range phone in a hot car. It has to be light on battery and data, and it has to survive a bad signal.

What is the admin dashboard for?

It's where you run the business. Nobody downloads it. You live in it.

• Approve or reject drivers, with their documents in front of you.
• Set fares by city and by vehicle type.
• Watch live trips on a map.
• Handle complaints, refunds and disputes.
• See the numbers: rides, cancellations, earnings, what drivers owe.

If the dashboard is weak, you'll be running the company from WhatsApp and a spreadsheet within a month. It's the first thing I'd ask a developer to show me.

What is the hidden fourth part?

The engine. When a rider taps confirm, something has to find the nearest free driver by road, offer him the job, wait, and move to the next one if he ignores it. It has to price the trip, track it, take the payment and split the money.

It does this for every ride at once, in real time. This is where most of the build time goes, and it's why a ride-hailing platform costs what it costs. I went through the figures in what an app like Uber costs.

Which part do you build first?

The admin and the driver side. Not the rider app.

You can't take a single ride until drivers are signed up, checked and online. So sign-up, document checks and approval come first. While you are recruiting drivers, the rider app gets finished.

We learned the same lesson on our loyalty platform. The customer sees a card in their phone wallet and nothing else. The real work was the app behind the counter that staff use, and the dashboard behind that. The side the public sees was the smallest part.

What do founders get wrong?

They spend the budget on the rider app looking beautiful and treat the driver app as an afterthought. Then drivers hate it, go offline, and riders wait fifteen minutes.

Spend your money where the supply is. In ride-hailing, supply is drivers.

What should you do next?

List what each of the three has to do on day one. Keep each list short. Anything that isn't needed to complete and pay for a ride goes on a second list for later.

If you're building for Ghana or anywhere mobile money is the main way to pay, read how to build a ride-hailing app in Ghana first. And if you want it scoped properly, tell me what it has to do. It's the kind of platform we build.