Mobile money, entry-level devices, unstable networks, multiple currencies. What a Canadian-designed product has to change to work in West Africa.
A product designed for the Canadian market and deployed as-is in West Africa rarely fails on translation. It fails on technical assumptions nobody stated out loud — because they're invisible when they're true.
The invisible assumptions.
“The user has a credit card.” Credit card penetration is low across most West African markets. Mobile money, by contrast, is everywhere. If your payment journey assumes a card, you don't have an adaptation problem: you don't have a product in that market.
“The connection is stable.” It's intermittent, and it's billed by volume. An app that reloads its entire state on every screen costs nothing in Ottawa. In Lomé it costs the user credit, and they uninstall it.
“The device is recent.” The real installed base is dominated by entry-level Android with little memory and limited storage. A 90 MB app doesn't install on a device with 400 MB free.
“One currency, one tax.” The CFA franc is pegged to the euro at a fixed rate, which simplifies part of the problem — but exchange rates, transfer fees and local taxation don't fit in a configuration variable.
What it changes in design.
Offline first. The app has to work without a network and sync when it returns. That means a local operation queue, explicit conflict resolution and visible state handling. It's an architecture decision, not a feature — adding it later means rewriting the data layer.
Weight as a criterion. Set a byte budget — for the installed app and for each screen — and make your CI fail when it's exceeded. Without automatic measurement it grows every sprint and nobody notices.
Mobile money as the primary journey, not a secondary option tucked into a menu. The authorisation flows differ from a card's: confirmation by message, longer delays, intermediate states, silent failures. The journey has to be designed for that reality, not adapted to it.
Phone numbers as the identifier. Email is often secondary. International formats, portability, number reassignment by carriers — a number can change owner, and your account model has to expect it.
What it changes in operations.
Time zones and working days: Togo is on UTC, Ottawa moves between UTC−4 and UTC−5. A job scheduled “at midnight” runs in the middle of someone's day. Customer support: the preferred channel is frequently instant messaging rather than email.
And testing on real hardware. An emulator reproduces neither the slowness of an entry-level device nor a connection dropping mid-request. Buy two low-end phones and test on them. It's the highest-return spend on the project.
Design for the hardest constraint, then relax. The reverse is never true.●
A product built for an entry-level device on an unstable network runs perfectly on fibre in Ottawa. It's exactly the same reasoning as bilingualism designed in from the start, or compliance placed in week 1: a constraint integrated early costs little and improves the product for everyone.
What we don't do.
We don't “localise” a Canadian product for West Africa by changing the currency and the language. If the West African market is part of the plan, it enters the scoping phase in week 1 — on the same footing as the primary market.