USSD vs Apps: How to Actually Reach African Customers

A founder asks us to build them "an app" almost every week. Roughly half the time, once we understand who their actual customers are, the right answer is: don't build an app — build a USSD service. Not because apps are bad, but because the customer they're trying to reach doesn't have a smartphone, doesn't have consistent data, or isn't willing to download a 40MB app for something they'll use twice a month.

This isn't a niche consideration. Smartphone penetration across Sub-Saharan Africa sits well under 50% in most markets, and even among smartphone owners, data costs mean many people keep mobile data off by default. If your product depends on someone having an app open and connected, you've already excluded a large share of the population you're trying to serve.

What USSD Actually Is

USSD — Unstructured Supplementary Service Data — is the technology behind those *123# codes you dial that pop up a plain-text menu on any phone, smartphone or basic feature phone, with zero data required. It runs over the same signalling channel as a phone call, which means it works in areas with only the weakest GSM signal, works with zero airtime data balance, and works on a phone that costs $15.

It is, without exaggeration, the single most reliable way to reach a mass-market African audience. EcoCash itself runs on USSD as its primary channel in Zimbabwe. Most mobile money platforms across the continent do the same, precisely because reach matters more than a polished interface.

When USSD Is the Right Answer

• Your customer base includes rural areas, older demographics, or lower-income segments where feature phones are still common
• The interaction is simple and transactional — check a balance, register for a service, place a basic order, confirm a delivery, vote in a survey
• Reliability matters more than visual polish — you need it to work every time, on every phone, everywhere
• Data cost is a barrier for your users, and you don't want to make them spend airtime data just to use your service
• You need the broadest possible reach for something like a loyalty programme, a farmer registration drive, or a public health campaign

When an App Is the Right Answer

• Your users are already smartphone-first — urban professionals, younger demographics, businesses with staff who carry company phones
• The interaction is complex — multi-step forms, photo uploads, maps, dashboards, anything that needs more than a text menu can express
• You need offline data storage on the device itself, not just a transaction
• Brand experience and visual design matter to the product — a fleet dispatch app for drivers, a clinic app for doctors, a retail app for staff
• You need push notifications, camera access, GPS tracking, or other native device capabilities

Why Many Businesses Actually Need Both

The businesses that reach the widest market usually run a layered approach rather than picking one channel. A fintech or agri-business might use USSD as the universal front door — anyone with any phone can register and transact — while offering a full app for the smaller segment of customers who want richer features like transaction history, budgeting tools, or in-app support chat.

We've built this pattern for clients directly: a core transactional flow available on USSD for maximum reach, backed by the same underlying system that powers a smartphone app for users who have one. The two channels share the same backend and the same data — a customer isn't locked into one or the other, and the business isn't choosing between reach and experience.

What Building a USSD Service Actually Requires

An Aggregator or Direct Telco Relationship

USSD codes are allocated and controlled by mobile network operators — Econet and NetOne in Zimbabwe, MTN and Vodacom in South Africa, and their equivalents elsewhere. You can't just "build" a USSD service the way you build a website; you need a short code (a *XXX# sequence) assigned through the telco, either directly or through a licensed USSD aggregator who already has relationships and infrastructure in place. Direct telco relationships take longer to establish but usually cost less per transaction at scale; aggregators get you live faster but add a margin on top.

Session-Based, Stateless Design

USSD sessions are short-lived and stateless by nature — the network doesn't hold a persistent connection the way an app does. Your backend has to track exactly where a user is in a menu flow across each request-response cycle, handle session timeouts gracefully (typically 60–180 seconds per screen), and recover cleanly if a session drops mid-transaction. This is a genuinely different engineering discipline from building a web or mobile app, and it's where inexperienced teams get USSD wrong — sessions that lose state, menus that don't handle a mistyped digit, transactions that can't be safely retried.

Cost Structure

USSD isn't free to run. Telcos and aggregators typically charge per session, and in some markets the airtime cost of the session is passed to the customer (a small fee per USSD interaction) unless your business absorbs it. Budget for this as an ongoing operating cost, not a one-time build cost — it scales with usage, which is usually a good problem to have.

What Good USSD Design Actually Looks Like

A poorly designed USSD menu is a genuinely miserable experience — five levels deep, unclear numbering, no way to go back a step without restarting the whole session. Given how little screen real estate and time a USSD session offers, the discipline of good menu design matters far more than it would in an app where a confusing screen just gets a second look. The best USSD services we've built follow a few consistent rules: no more than four or five options on any single screen, the most common action always available as option 1, a way to go back one level without losing entered data, and confirmation screens before anything irreversible happens — a payment, a registration, a cancellation.

It's also worth designing for the reality that USSD users are often typing digits quickly from memory, on a numeric keypad, sometimes in poor lighting or while multitasking. Error handling has to be forgiving — a mistyped digit should prompt a clear retry rather than dropping the session entirely, because a dropped session on a feature phone often means the customer simply doesn't try again.

Questions to Ask Before You Commit to Either

• What phones does our actual customer base use — do we have real data, or are we assuming?
• Is the core interaction simple enough for a text menu, or does it genuinely need a rich interface?
• Are we building for reach (USSD), for experience (app), or do we need both feeding the same backend?
• Who handles the telco or aggregator relationship, and what's the per-session cost at our expected volume?
• Does our developer have real USSD session-handling experience, or would this be their first one?

What USSD Costs to Build and Run

Expect two separate cost lines. The build itself — the menu logic, session handling, and backend integration — is typically less expensive than an equivalent app, often a fraction of the cost, since there's no need for native mobile development, app store submission, or device-specific testing across dozens of Android and iOS versions. The ongoing cost is the per-session charge from the telco or aggregator, plus, in some markets, a short code lease fee paid monthly regardless of usage. For a business processing a meaningful volume of transactions, these per-session costs add up and should be modelled against expected usage before committing, rather than discovered on the first invoice.

The mistake we see most often isn't choosing the wrong channel — it's choosing a channel based on what feels modern rather than on where the customers actually are. An app is not automatically the better product. For a huge share of the African market, a well-built USSD menu still reaches more people, more reliably, than the most polished app ever will.

Keep Reading

• WhatsApp for Business Software: The WhatsApp API in Africa
• How to Build Business Software That Survives Load Shedding
• Mobile Money Integration for African Business Software
• Our Engineering Approach →