Qwiqe - Ride Hailing
Qwiqe is a ride-hailing platform built to operate in Nigeria and Canada at the same time, spanning a rider app, a driver app and an admin dashboard. Rather than shipping one product and translating it, Qwiqe runs a single shared architecture with genuinely different behavior underneath, because the two markets do not agree on how money moves.
In Nigeria the fare is paid after the trip, in cash or by transfer, directly to the driver, who then settles the platform's commission from a remittance balance the next working morning, before they can accept new rides. In Canada the rider's card is authorized before the trip begins and captured automatically on completion, with drivers paid out on scheduled cycles. Same interface, same visual language, two entirely different businesses beneath it.
The problem
Ride-hailing is a solved category. Everyone already has Uber, Bolt, Lyft or inDrive.
Another booking flow convinces nobody to switch. And the harder problem sat underneath that one: Qwiqe had to work in Nigeria and Canada at once, without becoming two products held together by a shared logo.
The obvious approach would have been to build one app and translate it. Early research made clear that would fail, because the differences between the two markets are not linguistic or cosmetic. They are operational. Money moves differently, and everything else follows from that.
Payment infrastructure is not a checkout screen
I approached payments as a checkout problem. They turned out to be the architecture the entire business runs on.
In Nigeria the platform never touches the fare. In Canada it touches nothing else. That single difference reshaped the driver app, the rider flow, and what the company actually is in each market.
N I G E R I A | C A N A D A |
|---|---|
The driver holds the money. The platform settles up afterwards. | The platform holds the money. The driver never touches it. |
|
|
What this meant for the design. Nigeria got a rider flow that treats cash as a first-class option rather than a fallback, and a driver app built around outstanding balance, daily earnings and settlement history. Canada got mandatory payment authorization inside the booking flow, deliberate friction, added because it matches what Canadian riders expect and it removes fare disputes between rider and driver entirely.
Two payment models, one visual language. The logic beneath diverges completely; the experience above it stays recognizably the same product.
Drivers need different things on the home screen
In Nigeria, settlement status decides whether a driver can work at all. It cannot be three screens deep.
N I G E R I A - D R I V E R H O M E | C A N A D A - D R I V E R H O M E |
|---|---|
|
|
Ride categories are market-specific
A flexible category framework, not one fixed set forced onto both countries.
N I G E R I A | C A N A D A |
|---|---|
|
|
The design move was building a category framework that accepts country-specific entries rather than hard-coding a list. The booking experience stays identical; what fills it is local.
Localization is not translation
One architecture, localised behaviour. The interface stays familiar while payment flows, categories and operational rules adapt underneath.
Two separate apps would have doubled the engineering cost and split the product in half. One rigid app would have felt foreign in at least one market. The shared architecture with localized behaviour was the only option that kept engineering complexity down while letting each market feel like the product was built for it.
Reflection
I wasn't designing for two countries. I was designing for two transportation economies.
Before this project I thought of localisation as adapting content for a region. Qwiqe taught me it starts much earlier, with how the business actually operates, how money moves through the system, and what users already expect because of both.
The payment finding is the clearest example. Treated as a checkout screen it would have produced a Canadian flow shipped into a Nigerian market, where drivers hold the cash and the platform is a settlement system. No amount of interface polish would have rescued that. The decision that mattered was made before any screen existed, by understanding the operational model first.
