They asked for a CRM.
The map said otherwise.
A telehealth company in Pakistan runs diabetes care over WhatsApp. We mapped their operation before we wrote any code. Then we built the system from the map.
Chosen over an in-house team and other builders.
Mapped before any code.
Rules decide triage. AI does not.
Went into production in mid-2026.
The gap between visits
A diabetic patient sees a specialist for a few minutes every few months. The condition lives in the time between visits. That is where readings drift, doses get missed and problems grow without anyone seeing them.
The partner’s patients are often elderly and do not use apps. Many have a son or daughter abroad who pays for the care but cannot see it. The partner wanted to close that gap without a large care team.
Care that only happens at appointments leaves the patient alone between them.
Care that happens every day, by hand, stops working after a handful of patients.
Before there was a contract
The partner had an in-house development team. They also had quotes from other builders. They chose us for speed and product judgment.
Before any contract, we built a demo to prove we understood the business. It was throwaway on purpose: no backend, built in days, shown in seven minutes. It had ten demo patients, and one of them could miss an insulin dose live in the room.
What the map showed
A CRM tracks people you want to convert. The partner described something else: four people looking at the same patient from four directions.
So we drew the operation before we built anything. Each view on the map became one part of the system.
The map
The patient
Answers on WhatsApp. Will not install an app.
What shipped
WhatsApp check-ins
Scheduled prompts with buttons, in English and Urdu. No app and no password. Replying STOP halts everything and alerts a person.
The map
The family
Pays from abroad. Wants to know their parent is fine.
What shipped
The family view
A locked, read-only link with status, appointments and a periodic report card. No clinical notes.
The map
The clinician
Needs to know who is at risk without reading everything.
What shipped
The care team desk
One board of every patient by status, a shared inbox and a task queue. Every change is in an audit log.
The map
The care plan
Decides what happens to each patient, and when.
What shipped
The care loop
Prompts on a schedule, rules that score each reading, and medication reminders from the real prescription.
The map preceded the product, and the product matches the map.
How the build ran
Each step removed a guess before code made it expensive.
Step 1
Flows first
We drew each flow and reviewed it with the partner’s team. No code existed yet, so every change cost minutes.
Step 2
Screens before systems
Next came a clickable mockup of every screen, with nothing behind it. It aligned the business before the build committed to anything. We closed each open question in writing.
Step 3
A spec, then the build
The specification decided the architecture instead of leaving it for later. Then we built against it. It went into production in mid-2026, and we kept improving it with real patients.
We also said no. An emergency-response feature and ambulance dispatch were discussed and dropped. They were not what the operation needed first.
The clinical rules are not ours. The thresholds, triggers and escalation rules came from the partner's medical team. We encoded their model. We did not invent one.
What we built
The partner's team calls it the care loop. Its job is to make sure a person only looks at the patients who need a person.
A prompt goes out
A scheduled WhatsApp message asks for a reading. The patient answers with one tap.
The reply is read
Each type of reading has its own parser. An unclear reply gets a follow-up in the patient’s language.
The reading is scored
Rules score it green, yellow or red. The thresholds are settings the medical team controls, not code.
The system acts
Green gets an automatic reply. Yellow creates a task. Red creates an urgent task and alerts the family.
A person decides
Only the exceptions reach the care team. A manual change of status needs a reason and a note.
We built it on Hakeem, our healthcare product: a care operations platform on WhatsApp. The partner got its own instance, under its own brand.
Run a care team? See HakeemMedication reminders
The system reads each patient’s prescription and turns it into WhatsApp reminders. AI reads the page. A person confirms every row against the original before any reminder goes out.
Prescriptions also list drugs a patient has stopped taking. The review step keeps those off the reminder list.
We built the verification gate and refused to build the auto-approve switch.
Tuned with real patients
We stayed with the first paying patients and shaped the system around how they reply.
One tap to reply.
Patients tap Low, Normal or High instead of typing a number.
Many readings, one message.
The system reads each value and files it in the right place.
Alerts in working hours.
Foot-health prompts run at midday, when the care team is on shift.
The pattern is not medical
We mapped an operation, won the work on that map and built a system that matches it. Then we stayed to tune it with real patients.
The same approach works anywhere information arrives faster than people can read it.
We map first, build second, and stay through the outcome.