Trubooker

The Idea

Trubooker came to us wanting to build what the brand's own tagline captures in three words: Ride. Earn. Grow. A ride-hailing platform connecting everyday riders across Lagos with local, independent drivers, built around the idea that drivers should have a real stake in a platform that's actually built for their city, not a global app adapted for it.

The Problem

A ride-hailing marketplace lives or dies on one thing: whether a rider can trust that the car showing up is the one the app promised, in real time, every time. That meant the backend needed to handle live location tracking, ride matching, fare calculation, and driver payouts simultaneously across potentially thousands of concurrent rides, while giving the operations team a single place to see the entire city's activity at once and step in the moment something went wrong.

Scope Alignment

We scoped the build around the three sides of the marketplace that actually needed to work together from day one:

Key Documents

Given how much of the product depends on real-time accuracy, discovery produced three documents before any build work started:

• A system architecture brief — mapping how ride state, live location, and fare calculation would stay consistent across riders, drivers, and the ops dashboard
• An operations workflow brief — covering how the support team would monitor, intervene in, and resolve issues on live rides
• A scoped build plan — sequencing what needed to work end-to-end before anything else

System Architecture

The hardest constraint was keeping a rider's view of "where's my driver" accurate to the second, across a city-wide map with hundreds of active rides at once:

• A real-time location pipeline — streaming driver GPS updates into a live map both riders and the ops dashboard could trust
• A ride-matching and dispatch engine — pairing riders with nearby available drivers and tracking ride state through request, assignment, and completion
• A payments and payouts layer — calculating fares per ride and settling driver earnings without manual reconciliation

Wireframes & UX Flows

We mapped the flows where a few seconds of confusion actually costs the business a ride:

• Rider flow — request a ride, watch the driver's live ETA, pay, and rate the trip
• Driver flow — go online, accept a ride, navigate, and see earnings update in real time
• Ops flow — watch live rides on a city map and step into any ride that needs intervention

The Lean Plan

The lean plan sequenced the build around proving the core ride loop before anything else:

• 1Ship live ride request, matching, and tracking first, since that's the loop the entire business depends on
• 2Bring driver payouts online next, once real ride volume existed to pay out against
• 3Layer in the full ops dashboard, promotions, and support tooling last

Success Story

Trubooker launched as a three-sided platform, rider app, driver app, and an operations dashboard, built on one real-time backend. The ops team now watches the entire city's ride activity from a single live map, drivers get paid against rides the system tracked automatically, and the platform has kept shipping since launch, now several versions in.