Building USSD & Mobile Money Services That Scale

Why USSD Still Matters Alongside Smartphone Growth

While smartphone adoption continues to grow in South Sudan, USSD remains the most universally accessible interface for digital services — it works on any phone, requires no app download, and functions without a data connection, which matters in areas where data coverage is patchy or expensive relative to income.

For mobile money specifically, this accessibility is the entire value proposition. A USSD-based service reaches a customer on a basic handset in a rural market town just as reliably as it reaches someone in central Juba with a smartphone, which is why operators and financial service providers continue to invest in USSD menus even as app downloads climb in urban areas.

The channel's simplicity is also its constraint. There's no rich interface, no images, and limited character space per screen, which means every design decision has to work within a much narrower set of tools than a mobile app or website would offer.

Designing Menus for a Numbered-List Interface

Designing a good USSD experience is a different discipline from designing an app. Every menu, every prompt, and every confirmation message has to be considered carefully, because users are navigating numbered menus with limited context and no ability to scroll back and check something the way they would in a visual interface.

Menu depth matters more than it seems. A service that buries a common action four menus deep loses users to timeouts and mistaken selections before they ever reach it — the most frequently used actions need to sit at or near the top level, even if that means a slightly less tidy information architecture.

Wording has to be unambiguous in a way ordinary app copy doesn't. "Confirm transfer of 5,000 SSP to 092XXXXXXX? 1. Yes 2. No" leaves no room for misreading, whereas vaguer phrasing invites the kind of mistaken confirmations that turn into real customer complaints about money sent to the wrong number.

Testing menu copy with actual users before launch, not just with the internal team that wrote it, catches problems a design review misses. A menu option that seems perfectly clear to the person who wrote it can read very differently to a first-time user navigating it at speed on a shared phone in a noisy market, which is exactly the environment a lot of real USSD usage happens in.

Reliability Is the Whole Product for Mobile Money

For mobile money and value-added services specifically, reliability matters more than almost anything else. A USSD session that times out mid-transaction, especially one involving money, erodes user trust quickly and generates support calls that are expensive to resolve, since the customer often can't tell whether the transaction went through or not.

This means the backend systems behind a USSD menu need to handle session state carefully, respond within tight time windows set by the telecom operator's gateway, and fail gracefully when something goes wrong — showing a clear "transaction failed, no funds moved" message rather than leaving a customer to wonder.

Idempotency is a technical detail that has outsized real-world consequences here: if a session times out and the customer retries, the system needs to guarantee it doesn't process the same transfer twice. Getting this wrong either loses money for the provider or double-charges a customer, both of which are costly to unwind after the fact.

Reconciliation between the USSD session log and the actual ledger movement needs to be near real-time, not an overnight batch job. A customer who calls a support line an hour after a failed transfer expects an answer about where their money is now, and a support agent who has to wait for tomorrow's reconciliation report to find out is going to give that customer a bad experience regardless of how solid the underlying transaction logic is.

Load Testing for Salary Day, Not Average Day

Scale introduces its own challenges. A service that works perfectly in testing with a handful of users can behave very differently with thousands of concurrent sessions during a promotional period or salary disbursement day, when transaction volume can spike well beyond typical daily patterns within a narrow few-hour window.

Load testing against realistic traffic patterns, not just average load, is essential before launch. A system sized for the average day will buckle on the days that matter most to the business — month-end, holidays, and the first days after a government or NGO salary disbursement — which are exactly the days a mobile money service can least afford downtime.

We build test scenarios around these specific spike patterns rather than generic load benchmarks, because a USSD gateway integration that passes a standard performance test can still fail under the particular burst pattern of, say, ten thousand civil servants checking their balance within the same thirty-minute window on payday.

What Our Telecom VAS Team Actually Builds

Our telecom VAS team builds and integrates USSD applications, SMS platforms and mobile money services for operators and the businesses that depend on them, with a focus on the operational realities of running these services at national scale rather than just the initial launch.

That includes the less visible parts of the system — session management, gateway integration, reconciliation between the USSD platform and the underlying mobile money ledger, and monitoring that flags a stuck session before it becomes a wave of customer complaints.

For businesses building a service on top of an operator's USSD and mobile money rails — bill payment, savings products, merchant payments — getting these operational details right from day one determines whether the service holds up once real transaction volume arrives, not just whether the demo works in a meeting room.

We also help clients think past launch, to the monitoring dashboards and alerting that tell an operations team a service is degrading before customers start complaining en masse. A USSD platform that goes quiet for even a few minutes during a peak window can generate a disproportionate number of support tickets, so catching a slowdown early, while it's still a minor blip, is far cheaper than responding to it after it's become a visible outage.