Localisation Beyond Translation: Building for East African Users

Most teams building software for the Kenyan or East African market treat "localisation" as a checkbox: translate the app into Swahili, add a KES currency symbol, call it done. That approach produces apps that feel translated rather than built for the people using them. Real localisation is about designing for how your users actually live, pay, connect, and interact — not just what language they read in. This matters whether you're a SACCO digitising member statements, a clinic building a booking system, a school managing fee payments, or a fintech trying to onboard customers in Kisumu, Eldoret, or Garissa.

Language Is the Easy Part — and You'll Still Get It Wrong

Swahili translation sounds straightforward until you actually try to do it for a financial or medical product. Formal Swahili used in government communication is not the Swahili people speak day to day. Urban users, especially younger ones, move fluidly between English and Swahili within a single sentence — sometimes called code-switching — and your product's tone needs to reflect that instead of sounding like a stiff translation from a textbook. A loan rejection message in overly formal Kiswahili can read as cold or even confusing to someone who would have understood a simpler, mixed-language explanation instantly.

Dialect and Regional Variation

Kenya alone has significant linguistic diversity beyond English and Swahili — and East Africa as a region adds Uganda, Tanzania, Rwanda, and beyond, each with their own primary languages and norms around formality. If you're building for a national or regional audience, decide early and explicitly which languages you will actually support, and resist the temptation to promise "local language support" broadly without the budget or team to do it properly. A half-translated app in three languages is worse for trust than a well-executed app in one or two.

Practical Advice

Work with someone who writes for your actual audience — a customer service agent, a field officer, a teacher — not just a professional translator unfamiliar with your product's context. Test microcopy (button labels, error messages, SMS notifications) with real users before shipping, because these short strings carry disproportionate weight in trust and comprehension, especially for financial or medical actions.

Designing for Mobile-First, Not Mobile-Adapted

Most of your users are on Android phones, often mid-range or older devices, connecting over mobile data rather than fixed broadband. If your product was designed as a desktop web app and then "made responsive," it will likely still assume more screen space, more reliable connectivity, and more forgiving data costs than your users actually have. Designing mobile-first means your core flows — registration, payment, checking a balance, booking an appointment — need to work cleanly on a small screen with minimal data transfer.

Data Costs Are a Real Constraint

A data bundle is money, and for many users it is a deliberate, budgeted expense. An app that loads large unoptimised images, pulls unnecessary data on every screen, or forces frequent re-authentication is quietly taxing your users every time they open it. Compress assets aggressively, cache what you can locally, and avoid auto-playing video or heavy media unless the user explicitly asks for it. If your analytics show high drop-off at a particular screen, check whether that screen is simply too heavy before assuming it's a UX problem.

Designing for Interrupted Connectivity

Connectivity in Kenya and the wider region has improved substantially over the years, but it is still variable — moving through a building, travelling upcountry, or simply experiencing network congestion can interrupt a session mid-task. Build forms and payment flows so that a dropped connection doesn't lose the user's progress or, worse, leave them unsure whether a transaction went through. Idempotent payment confirmations, clear "pending" states, and the ability to resume a form rather than restart it are not nice-to-haves here — they directly affect whether users trust your product with money or sensitive information.

Offline-First Where It Matters

For some use cases — a field agent collecting SACCO member data upcountry, a clinic nurse logging patient visits in an area with patchy signal — offline-first design isn't optional. Data should be captured locally first and synced when connectivity returns, with clear conflict-resolution logic if two people edit the same record while offline. This adds real engineering complexity, so scope it deliberately rather than bolting it on late.

Payments: M-Pesa Is the Default, Not an Add-On

For most Kenyan consumers and many businesses, M-Pesa is the default way money moves, not an alternative payment method tacked onto a card-first checkout. If your product's primary payment flow assumes a credit card and treats mobile money as a secondary option, you've built it backwards for this market. Design the core payment experience around STK push and till or paybill flows, and treat card payments as the addition, if you need them at all.

Forex Exposure on Tools and Infrastructure

Many of the cloud and SaaS tools businesses rely on — hosting, APIs, software subscriptions — are priced in US dollars. For a Kenyan SME or SACCO, this creates real, ongoing forex exposure: your costs can shift meaningfully with the exchange rate even if your usage doesn't change, and your revenue is almost certainly in shillings. When budgeting for a build or an ongoing subscription, model what a meaningful currency swing does to your monthly costs, and where possible, favour providers or pricing tiers that give you some predictability. This is a business planning issue as much as a technical one, and it's worth discussing openly with whoever signs off on your cloud budget.

Reconciliation and Receipts

Users expect an M-Pesa-style confirmation message — immediate, specific, and trustworthy — for any transaction. If your system's confirmation is delayed, vague, or arrives through a channel the user doesn't check, you'll generate support queries and erode confidence even when the underlying transaction succeeded. Build your confirmation and receipt flows with the same urgency and clarity people are used to from mobile money.

Compliance Isn't Optional Background Noise

Localisation also means building within the actual regulatory environment your business operates in, rather than importing assumptions from elsewhere. If you issue invoices or receipts, KRA's eTIMS requirements are directly relevant to how your system generates and records those documents — the specifics of what's required and how change over time, so confirm current requirements directly with KRA rather than relying on what a vendor or blog post told you last year. Similarly, if your product collects personal data — and most apps serving Kenyan users do, even just phone numbers and names — you have obligations under the data protection framework overseen by the Office of the Data Protection Commissioner. Don't guess at what's required; check current guidance directly with the ODPC, particularly around consent, data storage, and any cross-border data transfer your hosting setup might involve.

Where Your Data Actually Lives

Many popular cloud platforms host data outside Kenya by default. For some businesses this is a non-issue; for others — particularly fintechs, SACCOs, and health providers — data residency can be a genuine compliance consideration. Know where your data physically sits, understand what that means under current data protection guidance, and be able to explain it clearly if a regulator, auditor, or customer asks.

Small Details That Signal You Actually Understand Your Users

Names, Phone Numbers, and Identity

Rigid form fields built around Western naming conventions — a mandatory "first name" and "last name" split, for instance — don't always map cleanly onto how names work locally. The same applies to phone number formats: build validation that accepts the formats people actually type, including the common variations in how a Safaricom or other local number might be entered, rather than forcing a single rigid pattern that rejects valid input.

Dates, Numbers, and Currency Formatting

Display currency as KES clearly, format large numbers the way your users expect to read them, and be careful with date formats — day/month/year is the norm here, and a system defaulting to month/day/year will quietly cause real confusion and errors, particularly in anything involving deadlines or appointments.

Power Interruptions and Device Reality

Power interruptions are a normal part of operating in Kenya, and they affect your users' devices, your own servers if you self-host, and any physical infrastructure like POS terminals or card readers. Build in graceful handling for sudden disconnection, make sure locally hosted systems have sensible backup power or failover plans, and don't assume a server or device was shut down cleanly when debugging an issue — check for signs of an abrupt power loss first.

Testing With Real Users, Not Assumptions

The cheapest way to catch most of these problems is to test with real users early — not a polished usability lab session, just handing the product to an actual SACCO treasurer, clinic receptionist, or shopkeeper and watching them try to use it on their own phone, on their own network, in their own language mix. You will learn more from twenty minutes of that than from weeks of internal review. Budget time and a little money for this; it's far cheaper than fixing trust problems after launch.

A Practical Starting Checklist

Before you call a product "localised," check that it works well on a modest Android device over mobile data; that its primary payment flow is built around M-Pesa rather than treating it as secondary; that error messages and key microcopy have been reviewed by someone who speaks to your actual customers daily; that forms accept real local name and phone number formats; that your invoicing approach aligns with current KRA eTIMS requirements, confirmed directly with KRA; that your data handling has been checked against current ODPC guidance; and that your team has a plan for what happens when connectivity or power drops mid-transaction. None of this is exotic engineering — it's attentiveness to the actual conditions your users operate in, and it's the difference between software that feels imported and software that feels built for here.