Building Health-Tech Apps in India: Why the Architecture Has to Change, Not Just the UI
Most software teams treat "healthcare app" as a UI skin over their usual stack — same auth flow, same database patterns, same notification logic they'd use for a food delivery app, just with a stethoscope icon.
It doesn't work that way. The moment an application touches patient data, the architecture itself has to change — not the color palette, not the icons, the actual data model and access-control decisions underneath.
We've spent this year deep in a health-tech build, and this post is a straightforward account of what changes, why it changes, and what it costs you if you get it wrong — whether that cost is an App Store rejection, a DPDP Act compliance gap, or a real data breach.
1. Consent isn't a checkbox. It's a data model.
Most consumer apps store consent as a single boolean: agreed = true. That's fine when the stakes are a newsletter signup. It fails the moment a regulator — or a user — asks "what did I actually agree to, and when?"
Under India's DPDP Act, consent has to be freely given, specific, informed, and unambiguous. In practice, that means:
- Separate checkboxes for each distinct thing being agreed to (privacy policy, terms of service, marketing communications) — never one bundled "I agree"
- A versioned consent record: which policy version was in effect, and a timestamp of when consent was captured
- A rule that materially changed policies require re-prompting consent — old consent for an old policy version isn't valid going forward
This is a five-minute decision at the database schema stage. It's a much more expensive retrofit once real user data is already sitting in a users table with a single boolean column.
2. Row-Level Security isn't optional — it's the entire trust model.
In a normal SaaS product, a backend bug that leaks one user's row to another user is a bad day. In a health application, it's a reportable data breach with regulatory notification obligations.
The fix isn't "be more careful with queries." It's architectural: every query has to be scoped server-side, so that even a compromised frontend, a malformed request, or a developer mistake cannot return another patient's data — not "shouldn't," cannot, enforced at the database layer.
With Postgres-backed platforms like Supabase, this means Row-Level Security policies on every table that touches patient data, tested per role (patient, staff, admin) before every release — not assumed to work because the frontend "doesn't show that data."
A useful mental model here: treat authorization as the database's job, not the application's. Application-layer checks are a UX nicety. Database-layer checks are the actual security boundary.
3. Your notification copy is a compliance surface, not a copywriting choice.
This is the one that catches teams off guard, because it looks like a content decision, not an engineering one.
A push notification that says "Dr. Sharma is ready for you" seems perfectly friendly. It also puts a doctor's name — and by extension, the fact that this person is a patient of that doctor — on a lock screen, visible to anyone standing nearby. That's a health-context leak, and it's the kind of detail that never shows up in a product spec but absolutely shows up as an App Store or Play Store rejection reason.
The safer pattern:
| Don't | Do |
|---|
| "Dr. Sharma is ready for you" | "Your appointment status has changed" |
| "You are #2 in queue at Andheri Clinic" | "Your turn is approaching" |
| Full name in SMS body | Generic status + call to action |
The rule of thumb: if a notification is visible on a lock screen or in a preview pane, it should reveal that something changed, not what it is.
Both Apple and Google explicitly reject health-category apps that require users to email support to delete their account and data. It has to be:
- Self-serve, from within the app
- A genuine deletion or anonymization of personal data — not just hiding a row with a
deleted flag
- Confirmed with a clear, unambiguous warning before it happens, and irreversible once confirmed
A reasonable implementation: soft-delete the account, anonymize personally identifying fields (name, phone), and retain only anonymized operational records for aggregate analytics. This satisfies both the user-rights requirement and any legitimate need to keep aggregate historical data intact.
5. The strongest security decision is often what you refuse to collect.
The best security decision on this project wasn't a clever encryption scheme. It was refusing to collect diagnosis, prescription, or medical history data in the MVP at all.
Data minimization isn't a limitation you accept reluctantly — it's a genuine compliance and security strategy. Data you never collect can't be breached, can't be subpoenaed, can't be misused by an insider, and doesn't need a retention policy. Before adding any new field to a health application's schema, the right question isn't "could this be useful someday" — it's "do we need this for the feature we're shipping right now."
None of this is exotic
Every item above comes from three sources that are publicly available and worth reading properly before writing a line of code:
- India's DPDP Act 2023 and the interim SPDI Rules that govern until it's fully enforced
- The OWASP Top 10, applied specifically to how patient data moves through your system
- Apple's and Google Play's health-category app guidelines, which are considerably stricter than their general app requirements
The pattern we keep seeing is teams treating compliance as a launch-week checklist instead of a design constraint from day one. It's cheaper, by a wide margin, to build these decisions into the schema and the RLS policies from the start than to retrofit them onto a database that already has real patient data sitting in it.
If you're building in health-tech, fintech, or another regulated space in India and want to compare notes on architecture or DPDP Act implementation, get in touch — we're always glad to talk shop with other teams doing this properly.
