← Back to all work
Ride-Hailing

Both sides of a ride-hailing network, live in Australia

Two apps built to work as one system. One for passengers booking a ride, one for drivers earning from it, running across Australia on both app stores.

Both sides of a ride-hailing network, live in Australia
IndustryRide-Hailing
PlatformiOS and Android
Year2024
Read6 min read
2
Apps built as one connected system
4
App store listings live and maintained
0
Cash handled by drivers or passengers
At a glance
SectorRide-hailing
Apps builtPassenger and driver
PlatformiOS and Android
MarketAustralia
PaymentsCard, no cash
Year2024
The problem

A ride-hailing service is really two products

Everyone thinks of the passenger app. Open it, pick a destination, watch a car arrive. But that experience only works if a second app, the one the driver is using, is doing its job at the same moment.

The two have opposite needs. A passenger wants simplicity and certainty: what will it cost, how long until it arrives, is this driver safe. A driver wants control and clarity: how much will I make, what is the best route, when do I get paid.

A ride only happens when two strangers, two phones, and one map agree on the same thing at the same time.

Build one well and the other badly and the whole service fails. A passenger with a perfect app still waits half an hour if drivers cannot see requests properly. The client needed both, built to work as a single system.

The challenges

What had to line up on both sides

01

Two apps, one moment

When a passenger books, a driver has to know within seconds. When a driver accepts, the passenger has to see it happen. The two apps are separate downloads but have to behave like one thing.

02

Location that keeps up

A map showing where a car was thirty seconds ago is worse than no map. Position has to update constantly, on phones that vary wildly in age and signal quality, without draining a battery a driver needs for a full shift.

03

Money that cannot go wrong

Passengers are charged automatically at the end of a trip. Drivers are paid automatically for it. Neither side is in the room to check. Every fare has to be calculated, charged, and recorded correctly the first time.

04

Safety on both sides

A passenger is getting into a stranger car. A driver is letting a stranger into theirs. Both need to know something about the other before the door opens.

What we built

How the two apps fit together

We built them as one system with two front doors. The same trip data, the same map, the same fare, presented differently depending on which side you are on.

How the two apps fit together
01

The passenger side: book, watch, pay

A passenger books in a few taps, either for now or for later. Before confirming they see what it will cost. Not an estimate that changes at the end, the actual price.

Once a driver accepts, the passenger watches the car approach on a live map with a real arrival time. That single feature removes most of the anxiety of waiting, because the uncertainty is what makes waiting feel long.

Payment happens by card at the end of the trip. No cash, no fumbling, no working out a tip at the roadside. The passenger closes the door and walks away.

02

The driver side: earn on your own terms

Drivers choose their own hours. Some work full time, some fit it around other jobs. The app does not push a schedule at them.

Ride requests arrive as instant notifications with the details attached, so a driver can decide quickly rather than accepting blind. Navigation is built in and accounts for live traffic, which matters because a driver paid per trip loses money sitting still.

Earnings are visible as they happen and transfer automatically. A driver can see what they made today without doing arithmetic at the end of a shift.

03

The shared parts underneath

Both apps sit on the same trip system. When a passenger books, that request goes out to nearby drivers immediately. When one accepts, the passenger app updates in the same moment. Neither side is polling or waiting for a refresh.

The map, the route, and the fare are calculated once and shown to both people. There is no version of a trip where the passenger and the driver are looking at different numbers.

04

Safety built into both

Drivers are checked before they can take rides. Passengers are vetted too, which drivers notice and appreciate, because most ride-hailing safety features only run in one direction.

Both sides rate each other after a trip. Ratings are visible before a trip starts, so nobody gets in a car knowing nothing about who is in it.

Support sits inside both apps. A driver dealing with a problem at two in the morning does not need to find a phone number.

Capabilities

What both apps do

01

Book now or later

Passengers request a ride immediately or schedule one in advance.

02

Live tracking

Both sides see the same car on the same map, updating as it moves.

03

Price before you ride

The fare is shown up front and does not change at the end.

04

Instant ride requests

Drivers get notified with enough detail to decide in seconds.

05

Built in navigation

Routes account for live traffic, so drivers spend less time stationary.

06

Automatic payment

Cards charged at the end of the trip, earnings transferred to drivers without chasing.

07

Two way ratings

Drivers and passengers rate each other, and both can see it beforehand.

08

In app support

Help available inside both apps at any hour.

Technology

The stack, by layer

The apps
Fl
Flutter
One codebase, four store listings
Gx
GetX
Keeps trip state in step across screens
Live features
Ap
REST APIs
Moves trip and fare data between both apps
Gp
GPS and location
Live position, routing, and arrival times
Nt
Push notifications
Ride requests and status updates
Money
Pg
Payment gateway
Card payments and driver payouts
Outcome

Two apps, four store listings, one working service

Both apps went live on the App Store and Google Play and run across Australia. Passengers book, watch, and pay without touching cash. Drivers set their own hours and see their earnings as they go.

Building them as one system rather than two projects is what makes the timing work. A booking reaching a driver in seconds is not a feature you can add afterwards. It has to be the thing the whole system is built around.

More work

Other things we've shipped

Start a project

Got something harder than this?

Tell us what isn't working. We'll tell you honestly whether we're the right team to fix it.

We reply within one working day.

First conversation is a scoping call, not a pitch.

If it isn't our kind of problem, we'll say so.