The product
Designing an asynchronous telehealth experience around one question: “Who can help me right now?”
Medichat.in is an asynchronous telehealth platform — live, in production, and used by 20+ certified and verified doctors — designed to reduce the friction between a patient’s healthcare need and an appropriate doctor who can actually help.
From the mobile app, a patient can:
- Find doctors based on their healthcare need
- Discover nearby doctors
- Identify doctors who are currently available
- Reach out to an available doctor
- Consult asynchronously — record symptoms on video and receive a prescription without a live session
On the doctor side, the product surfaces patients whose needs match the doctor’s specific specialization, while availability determines whether the doctor can receive a consultation.
The problem
Most telehealth optimizes for discovery — not for the patient’s immediate need
Most healthcare platforms optimize for discovery, appointments, or remote consultation. But those aren’t always the patient’s immediate problem. Sometimes the patient is effectively asking:
“I need medical help now. Who can actually help me?”
That led to the core product hypothesis:
If Medichat combines patient need + doctor specialization + doctor availability, it can reduce the friction between needing help and reaching an appropriate doctor.
Product thesis
From appointment marketplace to asynchronous consultation
The key design decision was to move away from a traditional:
- Search
- Profile
- Appointment
- Wait
- Consultation
- Need
- Record symptoms
- AI triage
- Doctor review
- Prescription
This is a fundamentally different mental model. The product isn’t primarily trying to become another healthcare directory or appointment marketplace — it is focused on making the asynchronous consultation work.
Competitive landscape
A narrower position, chosen on purpose
Medichat was designed with existing telehealth products such as Practo and eSanjeevani in mind.
Practo
A broad healthcare ecosystem with doctor discovery, appointments, online consultations, and other healthcare services. Its strength is breadth and a mature healthcare marketplace model.
eSanjeevani
A public telemedicine platform designed around structured telemedicine delivery, including specialist routing and remote consultation. Its strength is healthcare access at institutional and public-health scale.
| Dimension | Practo | eSanjeevani | Medichat |
|---|---|---|---|
| Primary model | Healthcare ecosystem | Public telemedicine | Asynchronous telehealth |
| Doctor discovery | Strong | Structured routing | Availability + specialization |
| Appointment model | Core | System-dependent | Not the primary interaction |
| Consultation model | Live video + appointments | Structured remote sessions | Asynchronous review |
| Nearby doctors | Yes | Not primary proposition | Important discovery signal |
| Matching | Specialty/symptom based | Structured specialist routing | Specialization + availability |
| Scope | Broad | Broad/institutional | Focused |
Do one high-value interaction extremely well instead of reproducing an entire healthcare ecosystem.
The matching system
Relevance before availability
A critical product decision was avoiding a generic pool of “online doctors.” A patient should not simply be connected to whichever doctor happens to be online — the doctor should be relevant to the patient’s need.
Availability without relevance is not useful.
Matching begins with a deliberate signal: the patient records a short video describing their symptoms — where it hurts, for how long — and AI triage analyses it before it ever reaches a doctor. The specialty picker routes the case to the right part of the network.
Patient experience
A deliberately focused journey
- Identify the need — the patient enters through the mobile app and communicates what they need help with.
- Discover relevant doctors — the system surfaces doctors relevant to the patient’s requirement.
- Check availability — availability is visible as a meaningful product state.
- Reach out — the patient can initiate contact with an available, appropriate doctor.
- Consult asynchronously — a matched doctor reviews the recorded case and the prescription arrives on WhatsApp.
Nearby discovery
Proximity as a trust signal, not just a map feature
“Nearby” is not simply a map feature. For healthcare, proximity can represent:
- Trust
- Convenience
- Potential continuity of care
- Easier escalation when an in-person visit becomes necessary
Medichat therefore treats proximity as a discovery signal alongside specialization and availability. The product supports two related intents:
“I need a doctor who can help me now.”
“I want help from a doctor near me.”
Those intents can overlap — but they are not assumed to be identical.
Doctor experience
The other half of a two-sided matching system
The doctor side is the other half of the product. A telehealth marketplace fails if doctors receive irrelevant requests. The doctor needs to quickly understand:
- Is this patient relevant to my expertise?
- Does the patient’s need match my specialization?
- Am I currently available?
- Do I want to accept this consultation?
This creates a two-sided matching system:
- Need
- Specialization
- Available doctor
- Availability
- Matching patient
- Consultation
The design challenge was therefore not simply creating two interfaces — it was designing a shared state system between two different users.
Availability as a product state
Not a badge — a state machine
One of the most important design decisions was treating availability as a system state rather than a decorative status badge.
Each state affects what the patient can do and what the doctor can receive. The UI needs to reflect operational reality:
If the product says a doctor is available but the doctor cannot respond, trust breaks immediately.
States are equally explicit on the patient side — a case can be processing, claimed, cancelled, or complete, and the UI makes the difference visible.
Trust & verification
Verification is part of the user experience
Healthcare has a higher trust threshold than most consumer products. Users need confidence in:
- Who the doctor is
- What the doctor specializes in
- Whether the doctor is verified
- Whether the doctor is available
- Whether they can safely initiate a consultation
Medichat is currently used by 20+ certified and verified doctors — so verification is not just an administrative backend concern. It is part of the user experience.
Trust modelCredentials + specialization + availability
Asynchronous telehealth
A different set of UX requirements than booking or live sessions
The defining product characteristic is that Medichat is asynchronous. The patient records a short video describing their symptoms, AI triages the case, and a matched doctor reviews it on their own time — no live session has to be scheduled. The prescription is delivered to the patient’s WhatsApp.
- Select doctor
- Select slot
- Book
- Wait
- Record symptoms
- AI triage
- Doctor review
- Prescription on WhatsApp
The asynchronous model removes the scheduling constraint — but it trades away the back-and-forth of a live session. That trade-off needs to be communicated honestly through case states, triage updates, and clear expectations for when the doctor will respond.
Key trade-offs
Five judgment calls, each a deliberate decision
Senior product design is as much about deciding what not to optimize as what to optimize.
| Trade-off | Decision | Why |
|---|---|---|
| Speed vs clinical appropriateness | Specialization match first, availability second | An appropriate available doctor beats the fastest available doctor |
| More choice vs faster decisions | Prioritize relevant doctors, not a large marketplace | Less choice → faster decision → clearer intent |
| Nearby vs best available | Location as a discovery signal, not a ranking rule | Proximity matters, but it is not absolute |
| Scheduled sessions vs asynchronous review | Optimize for a doctor reviewing the case without a live session | The experience does not pretend to be a live consultation |
| Broad platform vs focused product | Record symptoms → AI triage → doctor review → prescription | Reduced scope, sharper core value proposition |
An appropriate doctor reviews your case — without a scheduled live session.
The two-sided system
Two users whose actions affect each other across time
The most interesting design challenge wasn’t an individual screen. It was the interaction between two users whose actions affect each other across time.
Patient
Needs certainty that someone appropriate can help.
Doctor
Needs certainty that the patient is relevant and that the consultation request is actionable.
The product therefore had to account for state changes, timing, and edge cases — not just ideal happy paths.
Production changes the design problem
From screens to system states
| In a prototype | In production |
|---|---|
| Doctor = available | A doctor can become unavailable while a patient is viewing the screen |
| Every request can be perfectly matched | Some specializations may have fewer available doctors |
| The user completes the flow | Users hesitate, abandon, return, misunderstand states, and need reassurance |
Building Medichat as a production product changed my design focus from screens to:
- System states
- Edge cases
- Matching behavior
- Availability reliability
- Trust
- Failure recovery
- Operational constraints
AI-assisted product development
AI accelerated execution. Product thinking determined what was worth building.
Medichat was created as an AI-assisted side project. The mobile app is built with Expo (React Native), while Claude Code and ChatGPT Codex carried large parts of the engineering load across both the mobile app and the desktop platform — compressing the distance between idea, exploration, prototype, implementation, and iteration.
But AI did not replace product judgment. The difficult questions remained human design questions:
- What should the core interaction be?
- What should “available” actually mean?
- How should doctors be matched?
- When should proximity matter?
- How much choice should patients have?
- What happens when no appropriate doctor is available?
- How do we preserve trust in a healthcare interaction?
AI accelerated execution. Product thinking determined what was worth building.
What I would measure next
Beyond interface quality, toward marketplace quality
Because Medichat is live, the next phase should move beyond interface quality toward marketplace and matching quality:
Match quality
Are patients reaching the right specialization on the first attempt?
Time to doctor
Patient request → appropriate doctor accepts. A critical metric for an asynchronous model.
Availability reliability
Doctor shown as available → successful connection. Can the availability model be trusted?
Consultation completion
How many initiated connections become completed consultations?
No-match rate
How often does a patient fail to find an appropriate available doctor?
Repeat usage
Do patients return because the asynchronous model provides meaningful utility?
Senior design takeaway
A connected product system, not a set of screens
The core insight from Medichat is not simply that it is another telemedicine app. The interesting product decision is treating availability + specialization + proximity as a connected product system.
Practo shows the value of a broad healthcare ecosystem. eSanjeevani shows how structured telemedicine can support healthcare delivery at scale. Medichat takes a narrower position:
When a patient needs help, reduce the distance between that need and an appropriate doctor who is actually available.
Designing that experience required thinking beyond screens. It required designing:
- A two-sided marketplace
- Case state management
- Doctor specialization matching
- Availability logic
- Location-based discovery
- Trust and verification
- Asynchronous consultation
- Failure states
- Operational constraints
And because the product is already in production with 20+ verified and certified doctors, the strongest part of the story is not what the product might become — it is what I learned from making a real healthcare interaction work.
