Every few months I get the same email. A health-tech company has built something that works well somewhere else — London, San Francisco, Dubai — and they are planning their India launch. The deck is excellent. The market sizing is enormous. The product is genuinely good.
And almost none of it will survive contact with an actual Indian patient.
I say this as someone who has made most of these mistakes personally. I built a telemedicine platform from nothing, wrote the workflows, recruited the doctors, and watched patients abandon my funnel at steps I would never have predicted. What follows is not market analysis. It is the list of things I wish someone had told me before I spent two years learning them the expensive way.
1. The prescription is not an output. It is a legal instrument.
In most products built outside India, the prescription is the last screen. The consultation happens, the clinician decides, and the system generates a document. It is treated as a receipt for the real work.
In India it is the work. Telemedicine practice guidelines place specific requirements on how a prescription is issued, what it must contain, and critically, how it is signed. A scanned signature dropped onto a PDF is not the same thing as a digitally signed document, and the difference is not cosmetic. It determines whether a pharmacy will honour it and whether the prescribing doctor is protected.
This has architectural consequences that reach backwards through the entire product. Your identity system, your document storage, your audit trail and your doctor onboarding all inherit requirements from this one artifact. Teams that discover it late end up rebuilding the core of their platform, because you cannot bolt legal validity onto a document pipeline that was designed to produce receipts.
2. Patients do not want your app. They want a doctor who speaks their language.
This is the finding that most reliably offends good product teams, because it seems to devalue the interface work.
A patient in Kerala choosing between a beautifully designed English-first application and a slightly clumsy interaction with a doctor who speaks Malayalam will choose the doctor, every time, without hesitation. Trust in Indian healthcare is local, linguistic and personal. It does not transfer from a brand, and it certainly does not transfer from a design system.
The practical implication is that language is not a localisation task to be scheduled after launch. It is the product. A company entering India with a plan to add regional languages in phase two has effectively planned to have no users in phase one.
3. Payment failure is a clinical problem, not a finance problem.
Foreign teams tend to treat the payment gateway as plumbing. Pick a provider, integrate, move on.
In India the gap between gateway providers in real-world completion rates is wide enough to change your unit economics outright. Two gateways that look identical on paper will not perform identically against the same traffic, and the only way to know is to run both and measure. I have seen a change of gateway move completion by several percentage points, which at any meaningful volume dwarfs the fee difference everyone spends their time negotiating.
There is a second-order effect that matters more. A patient who fails a payment mid-consultation does not simply retry. They abandon, and frequently they abandon the entire idea of online consultation, having concluded it does not work. A failed transaction is not lost revenue from one order. It is a lost patient, and often the people they would have told.
4. Your doctors are not employees, and that changes everything.
Most health-tech products built in the US or Europe assume salaried or contracted clinicians working defined shifts, inside a system that controls scheduling and enforces quality directly.
The economics of Indian telemedicine push strongly towards revenue-share arrangements with independent practitioners instead. This is not a detail of the payroll module. It reshapes the product. Doctors who are paid per consultation respond to entirely different incentives than doctors who are paid per hour. Scheduling becomes a marketplace problem rather than a rota problem. Quality control cannot rely on managerial authority you do not actually possess, so it has to be built into the workflow itself.
Companies that port an employment-model product into a revenue-share market usually discover this when their best doctors quietly stop accepting consultations, and nobody can explain why.
5. Most electronic medical record software is billing software wearing a clinical costume.
The major EMR systems were shaped by American insurance reimbursement. That is their real purpose, and clinical documentation is arranged around it. Every field, every code, every mandatory step exists because somebody eventually has to bill an insurer.
Remove the insurer, as most Indian consultations do, and you are left carrying enormous structural overhead for a workflow that no longer exists. Doctors feel this immediately. They experience it as software that fights them, and their response is the same everywhere in the world: they stop using it properly, and your clinical data quietly degrades into fiction.
I run a heavily customised open-source EMR for precisely this reason. Not because building it was enjoyable, but because the alternative was asking clinicians to perform data entry that served no one in the room.
The pattern underneath all five
Each of these looks like a separate problem. They are the same problem wearing different clothes.
Health-tech advice in India is overwhelmingly produced by people who have never run a clinical service. It is not wrong exactly. The market sizing is usually accurate, the competitive analysis is usually fair, and the strategic logic usually holds. It simply has no contact with the operational surface where products actually fail — the prescription that a pharmacy rejects, the doctor who stops answering, the patient who tries once and never returns.
You can only learn that surface by standing on it. The good news is that it is learnable, and most of these mistakes are far cheaper to avoid than to correct.
If you are building in this space, or bringing something into India or the Gulf, I take on a small number of advisory engagements — four hours a month, remote, working directly on exactly these questions. Capacity is four companies at a time.
