We hit 60,000 patient encounters a few months ago. I’ve been sitting with what that number means - not as a metric to put in a deck, but as five years of feedback about what actually works when you’re building health software in Kenya.
The pattern across all of it: adoption isn’t about technical sophistication. It’s about designing for how people actually behave, not how you’d like them to.
Lesson 1: Patients want problems solved, not apps
Early on we built things we thought patients would love - health journaling features, community forums for chronic disease support, a symptom tracker. Almost nobody used them. What patients actually wanted was to see a doctor quickly and get their medication without hassle.
The features that stuck were the boring ones: SMS appointment reminders, USSD-based booking for patients without smartphones, a simple screen showing where you are in the queue. No one tells you they love a well-designed queue display, but the complaint rate dropped significantly when we got it right.
Lesson 2: Clinicians optimise for speed
Clinicians see 30-50 patients a day. They don’t have time to learn a new system - they barely have time to use the old one. Anything that adds clicks without saving time elsewhere gets ignored.
The features clinicians actually thanked us for: auto-populated vitals from the triage screen, prescription templates for common conditions, pre-filled follow-up forms. The ones they quietly stopped using: detailed structured physical exam templates, optional patient education modules, any report that took more than 10 seconds to load.
Lesson 3: Defaults matter more than options
We spent a lot of engineering time building flexible booking flows. Patients could pick any available slot across any clinic. The result was decision paralysis - patients would start the booking process and abandon it halfway through.
We switched to a much simpler approach: “The next available slot is tomorrow at 10am at your nearest clinic. Confirm?” Completion rates went up. It felt like giving users less choice, but it was actually giving them a clear answer to the question they were really asking.
Lesson 4: Trust is earned through reliability
There was a period where we were shipping features fast and our uptime wasn’t what it should have been. Clinics started hedging - keeping paper backups, checking the system twice before trusting it. That trust is hard to rebuild.
The investments that paid back the most weren’t features - they were the boring infrastructure work: offline-first data sync so the app kept working during connectivity drops, page load times under 2 seconds, queue state that stayed consistent across devices. Clinicians started trusting the system again when it stopped surprising them.
Lesson 5: Feedback loops must be immediate
We used to send patient satisfaction surveys the day after a visit. Response rates were around 8%. The responses we did get were vague and hard to act on.
We replaced them with a simple in-app rating immediately after the visit - one question, five stars, optional comment. Response rates went to 65%. More importantly, we started catching specific issues in real time: a doctor running unusually late, a payment process that was confusing, a clinic that was cold and uncomfortable. Things we could actually do something about.
Lesson 6: Personalisation is powerful but expensive
We tried building fully personalised patient experiences - custom messaging based on condition history, appointment recommendations based on past behaviour. It was technically interesting and genuinely underused.
The version that worked was much simpler: segment patients by broad condition category (diabetes management patients vs general outpatient visits, for example) and tailor the messaging for each group. You get maybe 80% of the benefit of true personalisation at a fraction of the engineering cost. At our scale, that’s the right trade-off.
The thing that ties all of this together: the most impactful work we’ve done has been simple, reliable, and built around what people were already trying to do - not what we thought they should want to do. We’ll keep building on that.