A nurse at a county health centre in a rural area has a patient who needs a specialist consultation. The nearest specialist is three hours away by matatu. The patient cannot afford the trip. The nurse pulls out her phone, opens the clinic's telemedicine app, and starts a video call.
Then the video freezes. The call drops. The nurse tries again — same result. After ten minutes of failed attempts, she gives up and tells the patient to come back next week when the specialist might visit.
That scenario plays out thousands of times a day across Kenya. Not because telemedicine is a bad idea, but because most telemedicine apps are built for conditions that do not exist in most of the country.
This post is for anyone running a clinic, hospital, or healthcare organisation in Kenya who is thinking about building a telemedicine app. I am going to tell you what actually works when the internet is slow, patchy, or absent — and what is a waste of money.
The Assumption That Kills Most Telemedicine Projects
Most telemedicine apps are designed in places where fibre is everywhere, 4G is fast and cheap, and power cuts are rare. They assume a steady, high-bandwidth connection. They use real-time video as the default consultation mode. They upload every image and form to the cloud immediately.
From our experience, none of that works for a patient in a rural area using a budget Android phone on a prepaid data bundle that costs KES 20 a day.
According to the Communications Authority of Kenya's Q2 2025-2026 sector statistics report, mobile internet subscriptions continue to grow, but the quality of that connection varies enormously. A user in an urban centre might get 20 Mbps. A user in a rural area might struggle to hold a 1 Mbps connection. That gap is not closing fast enough to assume universal fast internet anytime soon.
If you build an app that requires a fast, stable connection to do anything useful, you have built an app that most of your potential patients cannot use.
What to Build Instead: Offline-First, Android-First
The right approach is an offline-first architecture. That means the app does most of its work without needing the internet. It only connects when it absolutely has to, and it handles connection drops gracefully.
Here is what that looks like in practice.
1. Store Everything Locally First
When a nurse enters a patient's vitals, fills a consultation form, or takes a photo of a wound, the app saves that data on the phone immediately. It does not wait for a server response. The patient record exists on the device right away.
When the phone finds a usable connection — even a weak one — the app syncs the data in the background. The nurse does not need to think about it. The patient does not need to wait.
This is not complicated to build. It just requires the development team to think differently from the default assumption of "always online." At KEPAS, we have seen this approach work well for field data collection apps, and the same principles apply to telemedicine.
2. Ditch Real-Time Video as the Default
Real-time video is the most bandwidth-hungry feature you can include. It is also the least reliable on a weak connection. Do not make it the primary way patients and doctors interact.
Instead, build for asynchronous communication first:
- Store-and-forward messaging — the patient sends a text description and photos. The doctor responds when they have a connection. The messages sync automatically.
- Pre-recorded video — the patient records a short video explaining their symptoms. It compresses and uploads when a connection is available. The doctor watches it later.
- Voice notes — lighter than video, easier to send on slow connections, and often more informative than text.
- Scheduled video calls — for follow-ups where the patient can plan to be somewhere with a better connection, like a health centre with Wi-Fi.
This approach works because most consultations do not actually need real-time video. A dermatologist can diagnose a skin condition from photos. A general practitioner can assess a cough from a description and voice note. The cases that truly need real-time video — emergencies, complex procedures — are the minority, and they can be handled differently.
3. Compress Everything Aggressively
Images from a phone camera are typically 2-5 MB each. On a slow connection, uploading a single image can take minutes. The app should automatically compress images to a size that is still diagnostically useful but small enough to send quickly.
For example, a wound photo compressed to 200 KB is usually sufficient for a doctor to assess healing progress. That is 10-25 times smaller than the original. The app should do this compression on the device, before upload, so the user does not have to wait.
The same applies to video. The app should let users record at lower resolutions — 480p instead of 1080p — and compress the file before upload. The difference in diagnostic value is negligible. The difference in upload time is enormous.
From our experience, 93.56%— That is Android's share of Kenya's mobile operating system market, according to Statcounter's April 2026 data. If your telemedicine app does not work well on budget Android phones, it does not work for 9 out of 10 potential users.
Android-First Is Not Optional
According to Statcounter's mobile operating system market share data for Kenya, Android holds 93.56% of the market as of April 2026. From our experience, iOS is at 5.83%. Everything else is negligible.
That means your telemedicine app must be built for Android first. Not as an afterthought. Not as a port from iOS. Android-native development, targeting the version of Android that runs on the phones most Kenyans actually use.
Many budget Android phones in Kenya run older versions of Android — Android 10 or 11 are still common. They have limited RAM, often 2-3 GB. They have small batteries. They fill up storage quickly. Your app must be lightweight, efficient, and tested on the devices people actually own, not just the latest Samsung Galaxy.
Samsung leads the Kenyan smartphone market at 28.03% according to Statcounter's April 2026 vendor data, followed by Tecno at 13.99% and Infinix at 7.06%. These are the devices your app needs to work on. Build for the low end, and the high end takes care of itself.
M-Pesa Integration Is a Feature, Not an Add-On
If your telemedicine app does not let patients pay via M-Pesa, you are building a barrier between them and the care they need. M-Pesa is how healthcare payments happen in Kenya — consultation fees, medication costs, lab test deposits.
The app should integrate M-Pesa for payments natively. A patient should be able to book a consultation, pay the fee, and receive a confirmation — all without leaving the app. The payment flow must work offline too: the app records the payment intent locally and processes it when a connection is available.
From our experience, clinics that integrate M-Pesa directly into their booking flow see fewer no-shows and higher payment completion rates. The reason is simple: asking a patient to visit an agent to pay before a consultation adds friction. Letting them pay from the app removes it.
What This Costs
Let us talk money, because that is what matters to anyone making a budget decision.
A basic telemedicine app — patient registration, appointment booking, asynchronous messaging, M-Pesa payments — typically falls in the KES 500,000 to KES 1,500,000 range for Android development, based on rates from Kenyan development firms. That includes the mobile app, a simple backend, and basic admin panel.
A more complex app — with real-time video, electronic medical records integration, multi-facility support, offline sync, and advanced reporting — can range from KES 1,500,000 to KES 3,000,000 or more.
These are realistic figures for professional development in Kenya, as reflected in multiple published cost breakdowns from Kenyan firms. The biggest cost driver is not the platform — it is the complexity of the offline sync logic. Building reliable sync that handles conflicts, partial uploads, and reconnection gracefully is the hardest part of the project. It is also the most important.
Do not try to save money by skipping the offline work. An app that only works online is not a telemedicine app for most of Kenya — it is a toy for urban clinics.
The Infrastructure Reality Check
There is a reason telemedicine adoption in Kenya has been described as "moderate" in the academic literature. A systematic review published in Healthcare journal in March 2025 noted that Kenya has demonstrated moderate adoption of telemedicine, particularly through mHealth platforms, AI-enabled SMS interventions, and remote consultation services. The country's strong mobile-first approach has enabled cost-effective digital health interventions, especially for maternal and reproductive health, infectious disease management, and chronic care.
But the same review highlights the barriers: lack of internet coverage in rural areas, frequency of power outages, and the need for policy frameworks to support broader adoption. These are not theoretical problems. They are daily realities for the clinics and patients who would benefit most from telemedicine.
A telemedicine app that acknowledges these constraints — and works within them — has a real chance of being adopted. One that ignores them will sit unused on app stores.
What to Ask Any Developer Before You Start
If you are going to build a telemedicine app, here are the questions you should ask every developer or agency you talk to:
- How does the app handle losing its internet connection mid-session?If the answer is "it shows an error message," walk away.
- What Android versions does the app support?If they only target the latest two versions, they are not building for Kenya.
- How does offline sync handle conflicts?If two nurses update the same patient record offline, what happens when they both sync? A good developer will have a clear answer.
- What is the app's size on a phone?If it is over 100 MB, many users on budget phones will not be able to install it.
- How do you handle data privacy and the Data Protection Act?Patient health data is sensitive. The app must encrypt data both on the device and in transit.
Back to That Nurse
Let us go back to the nurse with the patient who needs a specialist consultation.
With an app built the right way, here is how it goes:
She opens the app. It works immediately because it does not need a connection to load. She enters the patient's details — name, age, symptoms, vitals — and takes a photo of the rash on the patient's arm. The app saves everything locally.
She selects a specialist from the list and sends the consultation request. The app compresses the photo to 150 KB and queues everything for upload.
The phone finds a weak 3G signal. The app syncs the data in the background — text first, then the photo. The nurse does not wait. She tells the patient to expect a response within 24 hours.
Later that evening, the specialist receives the consultation on their end. They review the details, look at the photo, and send a response — a prescription and a follow-up plan. The patient picks up the medication the next day.
The patient did not need to travel. The specialist did not need to be in the same room. The internet connection was slow, but the app did not care.
That is what a telemedicine app built for Kenya looks like. It is not about fancy features or flashy interfaces. It is about working reliably on the infrastructure that actually exists.
If you are building one, build it for the slow connection. Everything else is secondary.
Want to see what this looks like for your organization?
Talk to Us on WhatsApp