Riders name their own price, drivers compete with live offers, and the fare is agreed before the trip begins. Tuma Go is a bidding first ride hailing platform we designed, built, and shipped for African markets across five currencies and five languages.
Tuma Go set out to fix the part of ride hailing that riders complain about most, which is a fare they have no say in. Instead of an algorithm setting the price, the passenger enters the fare they want to pay, and nearby drivers respond with their own offers. The passenger then compares those offers by price, rating, vehicle type, and arrival time, and picks the one that suits the trip.
The platform runs on five currencies and five languages, so the same build serves Arabic speaking riders in North Africa, French speaking riders across Central and West Africa, and Portuguese, Spanish, and English speakers in the surrounding markets.
Adding another country is a configuration task in the admin panel rather than a new release, which keeps expansion fast and cheap for the client.
Egypt
Every real project has a few problems that decide whether it ships on budget or not. These are the four that shaped how Tuma Go was engineered.
Challenge:
Address search was the biggest running cost in the entire build. A basic integration sends one Places Autocomplete request on every single keystroke, so one passenger typing one pickup point could generate ten or more billable requests before booking.
Solution:
We wrapped the whole search into a single Google session token, so every suggestion request plus the final place lookup bills as one session instead of one call per letter. On top of that, the app waits until five or six characters are typed, debounces the input while the user is still typing, and requests full place details only when a suggestion is actually selected.
Challenge:
A bidding marketplace has to keep one ride request, several competing driver offers, and the passenger response in sync at the same moment. Ordinary request and response calls introduced lag, stale offers, and the risk of duplicate bids.
Solution:
We moved the entire negotiation onto persistent socket connections with one authoritative bid state held on the server. New offers, counter offers, acceptances, and expiries broadcast instantly to both sides. A unique key on each bid blocks duplicates from a shaky connection, and an automatic countdown returns the request to the driver pool if nobody responds in time.
Challenge:
The same app had to serve Arabic, French, English, Portuguese, and Spanish users. Arabic mirrors the entire layout from right to left, and loosely translated strings kept breaking fare labels, buttons, and address fields on smaller screens.
Solution:
We built the interface on a proper localization layer with fully mirrored right to left screen locale aware date, time & number format & translation files reviewed by native speakers rather than generated automatically. Rider switch language instantly without restarting the app & French stays the default because it covers the largest share of the market.
Challenge:
Five currencies with completely different fare ranges, plus a market where cash is still normal, meant a single fixed pricing model was never going to hold. Rounding and decimal rules also differ between the CFA franc zones and Egypt.
Solution:
Each country now carries its own currency, decimal rule, rounding step, minimum fare, and suggested fare band, all editable from the admin panel. Passengers bid in local currency and drivers see local currency, while cash, card, and wallet payments settle through one shared ledger so commission and reporting stay accurate across every market.
Three products, one connected platform, shipped as a complete working system. Everything the client needs to run a bidding marketplace without a second vendor.
Passengers and drivers share one app, so the interface has to make the switch feel obvious rather than clever.
Every feature below is live in the shipped product, not on a roadmap. Switch the tab to see what each side of the marketplace gets.
Enter the price you want to pay for the trip and let nearby drivers respond with real offers instead of a fixed rate.
Line up every incoming bid by price, rating, vehicle type, and arrival time, then accept the one that fits the trip.
Send a counter offer and settle on a fare with the driver directly, so both sides agree the price before the ride starts.
Follow the driver on the map from acceptance to drop off, with route, distance, and arrival time updating as the trip moves.
Share a one time code at pickup so the passenger and the driver both confirm they are starting the correct ride.
Book a trip for a set date and time, then let the app open bidding early enough to secure a driver in advance.
Build a multi stop route in one booking, so errands, school runs, and group pickups do not need separate rides.
Arrange a ride for family, friends, or staff, and send the trip details and OTP straight to the person travelling.
Review incoming requests with distance, route, and passenger offer, then quote a fare you are genuinely happy to drive for.
Turn on auto accept and take matching trips instantly, which keeps quiet hours productive without watching the screen.
See where requests are concentrated right now and reposition toward busy zones before the next wave of bookings arrives.
Choose a three, five, or seven kilometer search radius so the request feed only shows trips worth driving to.
Follow turn by turn GPS guidance to the pickup point and the destination without switching to a separate maps app.
Add, update, and switch vehicles from the profile, keeping registration details and documents current in one place.
Track completed trips, accepted bids, commission, and payouts, so daily and weekly earnings are always clear.
Register as a driver inside the app, upload documents for review, and start earning as soon as approval lands.
A bidding marketplace is harder to build than a fixed fare app, because two people have to agree before anything happens. This is the process we followed.
If you are planning a ride hailing app for your market, White Label Fox can get you there fast. We launch fully branded, production-ready platforms in 5 days.
Talk to an ExpertNothing exotic and nothing locked in, just a proven stack the client can maintain and extend. Here is what runs the Tuma Go platform today.
Flutter (Android And IOS)
Laravel (PHP)
MySQL
Firebase
AWS
Sinch (OTP & SMS)
Stripe
Google Cloud
Tuma Go is one of many on-demand platforms we have helped bring to life. Explore more White Label Fox success stories - from ride-hailing and delivery apps to full multi-service marketplaces - and see how startups and enterprises turned bold ideas into live, market-ready products.
