USSD application development
The whole market, one dial string — *384# works on every handset ever sold.
/ The problem
For registration, balance checks, voting, surveys, and agent workflows, USSD is still the widest pipe to the African market: it works on feature phones, needs no data, and everyone already knows how to dial it.
It is also an unforgiving medium. Sessions time out in seconds, screens are 160 characters, and there is no back button unless you build one. A USSD service that makes users re-dial three times is worse than no service at all.
/ How we deliver
We design USSD flows the way others design UIs — with journey mapping, screen budgets, and testing on real handsets over real networks. Menus are driven by a state machine with session persistence, so a dropped session resumes where the user left off instead of starting over.
Services integrate directly with your backend and with our payments and SMS infrastructure, so a USSD journey can check a balance, charge M-Pesa, and confirm by SMS in one flow.
/ What we build with it
Registration & onboarding
Sign-up flows that reach customers no app ever will — dial, answer, done.
Balance & status checks
Live queries against your backend answered inside the session in milliseconds.
Agent workflows
Float requests, stock reports, and confirmations from the field on any handset.
In-session payments
Trigger an M-Pesa STK push from inside the menu and confirm by SMS.
/ Capabilities
- 05.1
Dedicated and shared USSD code acquisition
- 05.2
Menu design and screen-budget optimisation
- 05.3
Session state management and resume-on-drop
- 05.4
MNO USSD gateway integration
- 05.5
Payments and SMS hooks inside USSD journeys
- 05.6
Load testing and real-handset QA
/ Spec sheet
The short version
How this service runs, in title-block form. Ask us for the long version.
- Codes
- Dedicated *XYZ# or shared *XYZ*NN#
- Sessions
- State machine with resume-on-drop
- Response
- Milliseconds from local state; slow work deferred
- Hooks
- Payments and SMS inside the journey
- QA
- Real handsets on real networks
/ How delivery runs
- 1
Journey design
Every screen is planned against a strict character and time budget — the back button is designed in, not hoped for.
- 2
Build & hook up
The menu state machine is built and wired to your backend, payments, and SMS confirmations.
- 3
Real-handset QA
The service is tested on real phones over real networks, including deliberate mid-session drops.
- 4
Launch & tune
Session analytics show where users stall, and the flow is tightened in the first weeks live.
/ Common questions
Shared or dedicated USSD code?
Shared codes (*XYZ*NN#) launch faster and cost less; dedicated codes are better for consumer brands. We run both and will recommend based on volume and branding needs.
How do you keep sessions from timing out?
Aggressive response-time budgets: menu logic answers from local state in milliseconds and defers slow backend work to async completion with SMS confirmation.
Can USSD take payments?
Yes — either through carrier billing on premium codes or by triggering an M-Pesa STK push from within the session.
/ Related services
/ Next step
Talk to us about USSD application development
Describe where you are — greenfield, half-built, or on fire. We answer with a technical read within one working day.
Start a conversation ↗