A paediatric clinic group in Bengaluru (5 locations across HSR, Indiranagar, Whitefield, Jayanagar, and Sarjapur) wanted a mobile booking app. The CEO had been quoted 5 months by another firm. We shipped a React Native app on iOS and Android in 7 weeks. The booking flow is built around what parents actually do on their phones — and around three compliance pitfalls that every clinic we have audited gets wrong.
The Answer in 60 Words
React Native (Expo SDK 51), Firebase Auth + Firestore for transactional data, a FHIR-lite resource model (Patient + Appointment + Practitioner + Slot), Razorpay for payments, and a 4-screen booking flow that completes in 38 seconds median. iOS + Android stores live in 7 weeks. DPDP + clinic-compliance shaped 14 specific UX decisions you can copy.
Why This Matters Now
The Indian paediatric clinic market is in two transitions at once. The DPDP Act 2023 turned "we use Google Forms for booking" from a Tuesday inconvenience into a Section 8 violation with up to ₹250 crore in penalties. And the Ayushman Bharat Digital Mission's ABDM 2.1 release in 2025 standardised the FHIR R4 profile Indian clinics are expected to align to, even if not yet enforced. Most clinics overlook both. We shipped this app with both in scope because doing them later costs three times as much.
The Client (Specific Details)
The Stack
The 3 Compliance Pitfalls Indian Clinics Overlook
This is the section you came for. Every clinic we have audited misses at least one of these — most miss all three.
Pitfall 1: Implicit consent at signup
What clinics do: present a "Sign up" button. Parent taps. Account created. The clinic's privacy policy is in the menu, somewhere.
What DPDP Section 6 requires: free, specific, informed, unconditional, unambiguous consent with clear notice. The notice must list the purpose of data collection (booking? marketing? insurance claims?) and the data fiduciary (the clinic group's legal entity name and its registered DPO).
Concrete fix we shipped: a 3-screen consent flow before any account creation. Screen 1: who we are. Screen 2: what we collect (mobile, name, child name, DOB, gender, weight at registration). Screen 3: what we use it for (booking, reminders, billing — three separate checkboxes the parent can toggle). A parent who declines "marketing reminders" gets zero promotional SMS — we wired the consent flag into the SMS dispatcher itself.
Pitfall 2: Medical records visible to receptionists who do not need them
What clinics do: receptionist's app shows full patient history, prescriptions, weight tracker, vaccination schedule. Because it is easier to build one view.
What both HIPAA's "minimum necessary" rule and DPDP Section 8 require: access only to what is needed for the task. A receptionist booking a slot does not need the child's vaccination history.
Concrete fix we shipped: 4 role views with deliberately narrowed access. Receptionist sees: parent name, child name, mobile, today's slot. Reception cannot view past visits unless they explicitly tap "Patient history (logs audit)" — which writes to an audit table the doctor and admin can review. Nurses see vitals and active prescriptions only. Doctors see everything for their own panel. The clinic owner sees aggregates, not individual records (this took two rounds to convince the owner of, but the auditor in March was very pleased).
Pitfall 3: Backup retention with no destruction policy
What clinics do: every Firebase / Google Drive / AWS backup retained forever. "Just in case."
What DPDP Section 8(7) requires: data retained only for the purpose for which it was collected, then erased. Backups count as data.
Concrete fix we shipped: an erasure pipeline. Active records: retained while patient is active + 3 years post-discharge (paediatric clinics: until 18 + 3 years post-last-visit, per Medical Council of India norms). Backups: 90-day rolling window in Firestore exports. Parents can request export + erasure via the app — a request fans out to admin (review), legal (sign-off), then a destruction job that purges Firestore + 3 backup generations. Median time from request to fulfilment in pilot: 7.2 days.
The Booking Flow (4 Screens, 38 Seconds Median)
The UI work that took us the longest was reducing the booking flow from 11 screens (the version the CEO's previous quote proposed) to 4. Parents booking a pediatric appointment at 11 pm on a weeknight are sleep-deprived and one-handed. Every removed tap is a real win.
The Trade-Off We Made
Best practice says "a mobile app for healthcare should support offline mode for triage." We did not build offline. The reason: parents in Bengaluru have reliable 4G/5G; the booking action is online-only by nature (slots are live-fetched); and adding offline support would have added 12 days to the build and required a more complex sync engine. We did a 2-day spike on offline, looked at the spec, and removed it from Phase 1 with the CEO's sign-off. The Phase 2 doctor-side app for in-clinic recording does support offline — that is the place it actually matters.
For the design rationale on this kind of pruning, our UI/UX designer Khushi wrote up the 4-screen reduction process in the project's internal Figma file. The principle she enforces: "If you can't justify the screen with a tap count or a number, cut it."
The 7-Week Build (Week-by-Week)
The Outcome (Numbers)
The CEO's testimonial: "The receptionist did not realise we had launched until day 4, because nothing broke."
What We Learned About Indian Parent Booking Behaviour
Three patterns from the first 60 days of analytics that surprised us:
We treat this build as the case study we point at when clients ask about our mobile work — same stack as TalkDrill, our in-house English speaking app for Indian adults (5,000+ active users), which gave us the React Native + Firebase muscle that made this 7-week timeline achievable.
When Not to Build a Custom Booking App
Skip the custom app if (a) you have under 60 appointments/day total across all locations — Practo's free tier handles that comfortably, (b) your parents are 80% over 55 and prefer phone calls (saw this with a geriatric clinic — the app saw 11% adoption in 3 months and we wound it down), or (c) you have a tight budget and under 4 months. In that case, a well-configured Practo + WhatsApp business setup is dramatically more economical.
The DPDP-Ready Booking-App Checklist
- 3-screen consent flow before any account creation, with separable purpose checkboxes
- Receptionist view restricted to today's slot data — past visits behind an audit-logged tap
- Erasure pipeline (parent request → admin review → legal sign-off → destruction across active + 3 backups)
- Data hosted in India region (asia-south1 / ap-south-1)
- Audit log on every read and write of patient data
- FHIR-aligned resource names so ABHA integration in Phase 2 is a wiring exercise, not a rewrite
- Apple Health Data Use disclosure completed honestly before App Store submission
- SMS dispatch coupled to consent flag; no marketing SMS to declined parents
Common Mistakes
Symptom: "Doctors keep asking us to make the app simpler." Cause: trying to be EMR + booking + portal in one app. Fix: separate apps per persona. Patients have the booking app. Doctors have a different one. Receptionists usually do not need an app at all.
Symptom: "App approvals are stuck at Apple." Cause: missing "How is health data used" disclosure or unclear data collection. Fix: complete Apple's Health Data Use disclosure honestly. If you say "we never share data with third parties," then disable the Razorpay device-fingerprint SDK or amend the disclosure.
Symptom: "Parents don't update the app." Cause: forced upgrades feel hostile. Fix: silent feature-flag gating instead. The app self-updates; the parent never sees a "you must update" wall.
Symptom: "Our doctors say the slot grid is wrong." Cause: time zone handling between server (UTC) and India display. Fix: format every datetime through a single utility that converts to Asia/Kolkata. Never trust JS Date's default behaviour across iOS and Android.
FAQ
How much does a clinic booking app cost in India?
It depends on scope. For a 3–10 location clinic group with iOS + Android + admin panel: fixed-price, 7–12 weeks. Ongoing run + small features are billed monthly. Below 3 locations, the math against Practo/Calendly + WhatsApp does not always work.
Is HIPAA relevant for Indian clinics?
HIPAA is a US law. It applies if you are processing data of US patients (e.g., NRI families abroad, embassy referrals). For Indian-patient-only clinics, the DPDP Act 2023 is the relevant framework. The patterns overlap significantly.
Should I use Firebase or build my own backend?
Firebase is fine for ≤ 25k users and standard CRUD. Above that, or if you need complex aggregations, move to a dedicated backend (Node.js + PostgreSQL). For a 5-clinic paediatric group, Firebase scales for years. We migrated a different client off Firebase at 80k MAU and that point.
What about ABHA integration?
The ABDM ecosystem now offers a Health Information Provider API for clinic apps to share records with patient's ABHA. We left this for Phase 2 — clinic group had 4% of parents with ABHA in pilot. Worth implementing once ABHA crosses 30% adoption in your patient base.
How long is the App Store review for healthcare apps?
iOS: 2–5 days if your privacy disclosure is honest and complete. Google Play: 24–48 hours. Both reject apps that mis-disclose health data collection. Plan for one rejection cycle on the first submission.
Do we need a doctor's app too?
Most clinics under 8 doctors don't. The receptionist's screen for the doctor's day is enough. Above 8 doctors, a doctor's app for "what is my schedule, what is the chief complaint, what are the patient's last 3 visits" justifies its build cost.
Can we self-host this instead of using Firebase?
Yes. PostgreSQL + Node.js + Redis + Firebase Auth (or Cognito) — we shipped that stack for a hospital chain in Phase 1. About 20% more build time, about 35% less monthly run cost at scale. Pick based on team capacity, not principle.
Need a Clinic or Hospital Booking App?
We build patient-facing mobile apps (iOS + Android + admin) for Indian clinic groups, diagnostic chains, and dental practices in the 3–15 location range. Fixed-price, 7–10 weeks to launch, DPDP-aware by default. First call is with the engineer who would lead your project.
Book a 20-min Call
