In short
- Problem
- Every existing answer to who holds a family's medical records has an owner problem. Hospital portals hold them hostage; aggregators take custody in exchange for access. Neither survives a relative in an emergency room in another city.
- Constraint
- Protected health information, one engineer, and no certification to hide behind. Anything that needed a second engineer to be safe could not be built.
- Decided
- Consent architecture first, everything hung off it. Guardrails in code rather than in prompts. Redact before write. Failure direction chosen per surface. Two refactors that shipped no features.
- Rejected
- The aggregator posture — access in exchange for custody. The faster product and the better-funded business model.
- Hardest
- Reconciling the right to erasure against tamper evidence. Blocking audit-log mutation protects the log and breaks a legal obligation; a cryptographic hash chain, planned, protects both.
- Built
- 227 endpoints, 74 tables, 7 services, 938 mobile tests, two full AI-assisted security reviews and the remediation that followed, and a restore drill measured at 23m 29s.
- Stage
- Submitted to the App Store and Google Play for review, launching in India first. The next evidence is whether the people this is built for understand and trust the consent model. DPDP-aligned and HIPAA-aligned; not certified, and phrased that way everywhere.
- Next
- A condition-first Knowledge Library, Vaulth for Doctors and Vaulth for Hospitals, all in active development. Beyond them, a tentative roadmap toward portable, consent-driven records across providers, insurers and public programmes.
Question
Who should hold a family's medical records — the hospital that produced them, the app that displays them, or the family they describe?
Every existing answer has an owner problem. Hospital portals hold records hostage to one provider. Aggregator apps take custody in exchange for access. Neither arrangement survives the moment that actually matters: a relative in an emergency room in a different city, needing a drug allergy off a discharge summary issued four years ago.
In India the records themselves are scattered further than the software assumes — across hospital silos, WhatsApp threads, prescription drawers and lab portals. So the product question is not "how do we display health data." It is who the canonical owner is, and whether the software will still behave as though they are the owner on the day it would be more convenient not to.
Vaulth's answer is a portmanteau and a stance in the same word. Vault plus health: a private, durable, family-owned custody layer. Prescriptions, lab reports, discharge summaries, vitals, medications and vaccination history, held under the family's control rather than borrowed from someone else's database.
The product sits deliberately across three categories that rarely coexist: a personal health record, a family caregiving platform, and a non-diagnostic clinical AI companion. One governing phrase decides every conflict between them — consent over convenience, custody over copy.
The test
Before the platform earns any scale claim, the consent thesis has to survive contact with the people it was built for.
The first learning loop is deliberately narrow: a primary custodian putting a family's scattered records in one place; a caregiver receiving exactly-scoped access that expires; and a clinician or first responder getting the smallest safe view without installing an app. The product is not proved when those flows exist in code. It is proved when those people understand what they can share, what they cannot, and why.
The first measures follow from that. Activation means a first record in the vault and the first moment it is useful; after that, the measures are about families and sharing rather than daily opens. Daily activity and notification clicks are intentionally not success criteria for a records vault. The next work is design partners and the evidence that decides whether the consent model holds.
Constraint
Protected health information, one engineer, and no certification to hide behind.
The data is PHI, so a mistake is not a bug
Everything in the vault is protected health information. A defect that leaks a medication list is not a defect; it is a breach, with a regulator attached. That single fact rules out the entire category of "ship it and iterate" decisions that make small teams fast.
It also changes what the product is optimising for. Trust becomes as load-bearing as usability, and correctness as load-bearing as speed. Patients withhold information when they do not trust how it will be handled — which means a health product nobody trusts is not merely commercially weak, it is clinically counterproductive. Privacy stops being a legal footnote and becomes part of the experience.
Bus factor one
I am the only engineer across the full-stack monorepo — backend, frontend, mobile, infrastructure and AI integration, alongside product, UX, security, DevOps and compliance. Anything that needed a second engineer to be safe could not be built. Anything that needed a second engineer to be reviewed had to have that review manufactured, which is decision 09.
My background is roughly six years in product management, UX and front-end development — a B.Tech in CSE and a dual Master's in HCI and Interaction Technology through EIT Digital, split between the University of Twente and Universidad Politécnica de Madrid — and a prior Product Manager role through April 2026. The backend and infrastructure depth is recent and deliberate. That is the honest shape of it, and it is also why the governance in section Governance exists at all.
Pre-certification, permanently phrased that way
The platform is DPDP-aligned and HIPAA-aligned. It is not certified, and every document, page and email says so in those words. India's DPDP Rules were notified on 13 November 2025 with full enforcement due in May 2027, which is precisely the window in which an unbacked compliance claim becomes its own legal exposure — under the very law you are claiming to satisfy.
Decision
Ten decisions. The first one determines the architecture; the last one determines whether any of the others can be trusted.
Decision 01
Consent is the product. The records are just what it governs.
I built the consent architecture first and let everything else hang off it. That ordering is the whole platform, so it is worth being concrete about what it means.
Caregiver access is scoped, and it expires. A grant names exactly what a caregiver may do and for how long, and every protected action checks it. "Medications only, ninety days" is a sentence the system can actually express and then enforce.
Ananya’s recordsShared with you
Access ends in 7 daysAccess ends in 30 daysAccess ends in 90 days
Medications
- Metformin 500 mg twice daily
- Amlodipine 5 mg once daily
Not shared with you
Lab reports
- HbA1c 6.9% 12 Sep
- Lipid panel 28 Aug
Not shared with you
Documents
- Discharge summary Aug 2026
- Prescription Sep 2026
Not shared with you
Appointments
- Cardiology follow-up 14 Oct
- Diabetes review 2 Nov
Not shared with you
Access ended
Ananya revoked this grant. The next request Ravi’s app makes is refused.
Every request re-checks this grant
Every external view of a record is time-bound, revocable and logged. A doctor gets a share link with an expiry, an access count and a revoke button. A first responder scans an emergency card that the owner can revoke instantly, and every scan is logged.
Family circles share shapes, not values. Inside a small, invitation-only circle, members see how things are trending rather than the raw numbers, and each person decides, one kind of data at a time, what the circle sees. The circle tells you your father's blood pressure is trending badly. It does not hand you his readings.
Dependant migration closes the loop on ownership: a child who grows up can claim their own account, and their entire health record transfers out of the parent's custody with them. Custody that cannot be handed over is not custody.
The product's own AI asks too. Before any document text is sent for AI analysis, the person is asked, with the processor named. Declining withholds only the analysis: documents are still stored, viewed and shared exactly as before. The gate fails closed, because a gate that fails open sends health records to a third party on the strength of an outage, and consent is tied to its wording, so changing the named processor asks everyone again. It is the consent thesis applied to the product's own pipeline.
Traded away: every convenience that assumes the app may read what it holds. No cross-user analytics, no aggregate insight products, no silent claiming of registered users as dependants, and a permanent commitment never to sell data — which is the one promise that ends the company if it is ever broken.
Rejected: the aggregator posture, where access is granted in exchange for custody. It is the faster product and the better-funded business model, and adopting it would have made every other sentence on this page dishonest.
Decision 02
Guardrails in code, not in prompts
Every AI capability in the product is non-diagnostic by construction. The way that constraint is enforced is the decision.
Every prose-generating call carries a safety instruction — no diagnoses, no starting, stopping or changing medication, deflect on emergencies. That is the part everyone does. The part that matters is what happens next: the output is checked in code, and anything that reads as medical advice is replaced with a safe deflection.
The failure mode this prevents is specific. A system prompt is a request to a probabilistic system, and the request is honoured most of the time. "Most of the time" is an acceptable standard for a summariser and an unacceptable one for a thing that might tell a diabetic to change their dose. A prompt is a request. A scanner is a control. Only one of them can be pointed at in an audit.
The same reasoning shapes the smaller defences. Text from an uploaded document is fenced off as untrusted input, so a prescription cannot pose as instructions to the model. And in the assistant, identity always comes from the session, never from the model: it can ask for a lab result, but it cannot choose whose.
Drug interaction checking stays on commercial models and authoritative sources, and is excluded from any self-hosting plan. It runs on every medication added, checks against the person's own allergies and conditions as well as their other medicines, and asks them to acknowledge what it finds.
Traded away: cost control and independence on the one capability where independence would be worth most. Interaction checking is the capability I am least willing to own the failure of.
Decision 03
Redact before write, not before display
The audit log records who did what to which record, across every feature in the product. Personal and health details are redacted before the row is written. Redacting at read time would have been half the work and none of the guarantee: it leaves the sensitive values sitting in a table, protected by the correctness of every future query written against it.
A failed audit write fails loud — it raises an alert rather than disappearing — because an audit log that silently stops recording is worse than none.
The hard part is a conflict between two rights. The right to be forgotten needs to change the record; tamper evidence needs it never to change; and no permission setting resolves that. The resolution is a cryptographic hash chain across the log, and it is planned: erasure will still be able to remove a person from the rows it leaves behind, and any other change will break the chain and show.
7 more decisions inside Continue the Vaulth AI case study Decisions 04–10 · vault architecture · AI layer · two security reviews · about 3,000 words Show all 7 remaining decisions ↓ Hide the full record ↑
Decision 04
Fail closed where it protects the user, fail open where it protects the user
Sessions are short-lived, and a person can sign out one device or all of them. Revocation is checked on every request, which raises the real question: what happens when the system that remembers revocations is unreachable?
That path fails closed. The alternative — treating a session that cannot be checked as not revoked — would mean an outage silently reinstates every session a user has ever revoked.
The login-lockout counters do the exact opposite and fail open, for the same reason read the other way: an outage must not become a global lockout that denies users their own records. The rule is not "fail closed"; the rule is that the direction of failure is chosen per surface, according to which way the user gets hurt.
The same posture runs through the infrastructure. Internal services refuse to start without their secrets rather than starting open.
Decision 05
Two refactors that shipped no features
This is the decision I would defend hardest, because both of these were expensive, invisible to every user, and correct.
The Flutter rewrite, then the redesign on top of it
The mobile client was rebuilt from scratch as a clean-architecture Flutter app. The legacy client was deliberately and fully discarded rather than incrementally migrated — only the logo, the locale files and the model documentation were salvaged.
Then, on top of that, a brand redesign across the whole app, executed as a behaviour-identical refactor: a new design system with no change to the logic underneath. Two full passes over the same surface, neither shipping a feature.
What it bought: a codebase where a change is a change rather than an excavation, and a test suite that has grown to 938 tests. What it caught: the app was never sending the user's preferred language back to the server, so AI summaries were arriving in English whichever of the six languages the user had chosen. A localisation feature that was live, tested, and doing nothing for anyone.
The job queue, migrated completely rather than partially
The background-job layer ran on a library that was no longer maintained. It was migrated in one complete pass, with integration tests against a real queue written first — the first test coverage that layer had ever had.
It was done completely rather than incrementally because of a standing rule: never run two versions of the same library at once. A half-migrated queue layer has two sets of semantics for the same operation and no way to reason about which one a given job got.
The tests earned their place before the migration finished. They caught two behaviour changes in the new library of the worst kind — the job completes, the count goes up, and the work never happens — and both were fixed before they shipped. The same pass surfaced older scheduling defects that had never announced themselves, and that no partial migration would have found.
Traded away: months of visible progress, as the only engineer. Both were the price of being able to change anything afterwards.
Decision 06
Never claim a certification you cannot back
"DPDP-aligned and HIPAA-aligned — not certified" is the standing phrasing everywhere, and it costs real conversion. What backs it is a set of controls that can be pointed at in code:
Right to erasure: re-authenticated deletion that reaches everywhere a person's data lives — records, files and sessions — and leaves only an anonymised trace that the deletion happened.
Right to portability: a one-step structured export of everything the account holds, built so that one failing category cannot void the rest.
An age gate, and consent for minors: an independent account needs its holder to be 18 or over, on every sign-up route, and the check fails closed. Anyone younger can only be a dependant, and adding one runs a parental-consent flow that records what was agreed. Identity-backed verification is planned.
Data isolation: every query scoped server-side to a resolved owner identity, never to an identifier supplied by the client.
Layered rate limiting sits under all of it, with dedicated limits on every public link. The sign-in limiter counts failures only: a brute-force attempt is a stream of failures, and a limiter that also counted successes would end up locking out the people it exists to protect.
Decision 07
Meet the documents where they already live
Records enter the vault three ways: web upload, mobile upload, and a WhatsApp message to a linked number. The third is the one that matters in India, because most prescriptions in India are already in a WhatsApp thread. Asking a family to re-photograph documents into a new app is asking them to redo work they have already done.
The implementation deliberately refuses to be a special case: a WhatsApp message is verified and then enqueued exactly like a web upload — same reading, same classification, same summarisation, same pipeline. A second ingestion path would have been a second set of bugs. The channel runs in production end to end, observed against the live stack rather than inferred from the code.
Decision 08
Six languages, for the people an English-only app leaves out
The platform ships in English, Hindi, Telugu, Kannada, Gujarati and Marathi — interface, AI-generated document summaries, and notifications. The people most likely to need a language other than English are exactly the aging parents the product is for.
Translation keeps pace with the product: the newest strings reach the Indian languages after English, and until then the app shows English rather than a gap. Upgrading how the vault reads documents, including beyond English, is next on the roadmap.
The same care applies to ABHA. India's health account number can be stored with a profile, and the product does not present itself as an ABHA integration today. Integration with ABDM — its health information exchange, consent manager and FHIR records — is on the roadmap.
Decision 09
Manufacture the review a team would have provided
A single engineer has no code review by default. So I built the friction.
An engineering constitution as a foundational governance document. Session-based development, where every working session runs read-only discovery first, then a hard sign-off gate, then bounded execution increments — no drive-by changes, strictly scoped. A technical debt register as a first-class tracked artifact. Eight CI jobs on every pull request. Branch sequencing discipline, one thing merged before the next branches. And local gates forced to match CI exactly, after repeated CI failures traced to a weaker local check.
The operating principle underneath is worth stating directly, because it came from being wrong repeatedly: every defect of real consequence lives in a seam — repo versus production schema, test database versus deployed database, script versus actual cloud state, config versus code. Which is why "live" is defined strictly as traffic is flowing, not that a code path exists and would work if someone provisioned it.
That definition earned itself. A production schema fork dating to April 2026 — ten hand-seeded migration files that had never actually been executed against the live database — sat undetected because the repository and the deployment each looked internally consistent.
The same discipline covers merging. A merge to main is a production deploy, so every pull request is re-verified against current main before it merges, not against main as it was when its checks last ran.
Decision 10
Treat a sign-off as a claim, including my own
Every published claim carries an explicit confidence label: Confirmed, Partial, or Inferred. Gate reports are required to re-verify sign-off claims against the underlying evidence rather than accept them.
That rule exists because sign-off documents produced three consecutive false claims: an inverted recommendation, an invented figure, and a reversed encoding call. Three in a row is not carelessness, it is a systematic property of documents written by the party being assessed.
Two related checks fall out of it. AI-generated evaluations that inflate their scores on re-asking, award the top mark on whichever dimension flatters the subject most, or resolve every contested point in the subject's favour are treated as carrying a sycophancy signature, and held to the same evidence standard as any other claim. And characterization tests must include mutation verification — proving a negative assertion actually goes red when the behaviour changes, because a test that passes while testing nothing is worse than no test at all.
The same rule reaches the user. Analysis outcomes are now recorded for every document, lab extraction, insight and interaction check. For anything processed before that record existed, the app says so instead of presenting a result it cannot stand behind.
The failure mode I watch for by name is the one this whole section is closest to: optimising for artifact quality at the expense of operational reality. Constitutions, design systems and documents are easier to make excellent than observability, error handling and verified production behaviour. Every count on this page carries its own counting method and grep, cross-checked adversarially before publication, for that reason.
The vault
Eight clusters, each with its own register.
The information architecture is organised around what each surface is emotionally for, not around the database. Health — vitals, alerts, medications, journal, labs — is calm and archival. Records — documents, medical history, vaccinations, reports, the ICE card — is the vault proper, plus exports. Care — doctors, appointments, family, circles, caregivers — is warmer and relational. AI is reserved and visually separated. Connect handles data entering and leaving. Settings, a lightweight unauthenticated Public tier for share and ICE links, and an internal Admin surface complete it.
What it does
Health. Vitals entered by hand or synced from Apple Health and Health Connect, with trends over time, comparison across family members, and alerts on thresholds the person sets — including a note to a caregiver when a reading is critical. A journal for mood, energy and symptoms on the same timeline as the vitals. Habits, cycle and pregnancy tracking.
Medications. Reminders, adherence, stock and refills, and an interaction check on every medication added.
Records. Documents from a camera, a file or WhatsApp, read and summarised in the person's language, organised into folders and searchable. Lab results drawn out of reports and tracked over time. Medical history, appointments, and vaccinations compared against India's national immunisation schedule.
Family and sharing. A profile for every family member, a family tree, family circles, scoped caregiver access, expiring share links for a doctor, and the emergency card.
AI. Document summaries, a weekly insight, associations in the person's own data, and an assistant that answers questions about their own records — all non-diagnostic, and all marked as AI.
Reports and account. PDF health reports for a doctor's visit. Sign-in with email, Google or Apple. Notifications that keep the details off the lock screen. A full export, and deletion that means it.
Accessibility. Six languages, adjustable text size, and light and dark themes — because the second-largest persona is an aging parent who did not sign up and will not be configuring anything twice.
The five people it is built for
| Persona | Need |
|---|---|
| Primary custodian | One trustworthy place; confidence that others can step in |
| Aging parent / dependant | Simple views, big text, their own language |
| Caregiver | Exactly-scoped access that expires |
| Doctor, transient | A clean, complete view with no app to install |
| First responder, anonymous | The few facts that matter in an emergency, and nothing else |
The last row is also the one screen where motion is explicitly forbidden. The emergency page renders instantly and statically, with zero animation, because the person reading it has ten to thirty seconds of attention and is not a user in any sense the rest of the product recognises.
Design decisions I made as well
The brand is deliberately institutional rather than clinical: a royal blue instead of the mint-and-teal healthcare default, a warm paper background rather than pure white, and green reserved strictly for data visualisation.
One rule in that system does real work: lavender is exclusive to AI. It appears on AI-generated content and provenance surfaces and nowhere else — never navigation, never chrome, never admin. In a product whose whole claim is that the user knows where their data came from, a colour that only ever means "a model wrote this" is a consent mechanism wearing a design system's clothes.
Numbers — vitals, lab values, exports — are set in a monospace face so they read as records rather than as running text. Motion is never bouncy: uploading a document should feel like sliding it into a vault, not like confetti. Illustration is isometric and architectural, deliberately avoiding both humanoid corporate illustration and the stethoscope-and-pill iconography that turns a vault product into a clinic product.
Even the copy has a banned list — empower, revolutionise, AI-powered, next-generation, unleash, "your health journey" — on the argument that the product's confidence should come from not needing to say any of them.
The AI layer
Seven capabilities, all of them rate-limited and none of them permitted to diagnose.
The seven are document analysis, a classification fallback for documents the first pass is unsure of, lab-value extraction, the weekly health insight, interaction checking, translation into the five Indian languages, and an assistant that answers questions about a person's own records. Each is limited per person, and its output is marked as AI wherever it appears.
The weekly insight, and why it is deliberately quiet
Once a week, the platform reads a person's recent vitals, medications, lab results, journal and conditions together and writes a short narrative: the trends that matter, what is worth raising with a doctor, and associations in their own data. The same data never produces the same insight twice, and people can say whether it helped.
It is the product's core retention loop, and it is deliberately toned down. A weekly summary of your family's health is not a Spotify Wrapped, and the moment it starts performing enthusiasm it stops being trustworthy.
Model governance
Every model change goes through a structured evaluation against a set of documents, diffing the outputs across versions, before it ships. A model upgrade is a behaviour change to an extraction pipeline, and the fact that it is one line in a config file is exactly why it needs a gate.
Model choice is also bound by data residency. The published privacy policy commits to processing in India, so a model is only eligible if it is served from there. The defaults in the source match what production runs, and a test pins them.
The numbers
A census of the current release, counted from the repository rather than estimated.
- 227API endpoints
- 74Database tables
- 938Mobile tests, all passing
- 7AI capabilities, none diagnostic
- 23mRestore drill, measured: 23m 29s
- 6Indian languages
Infrastructure, in principle
A managed database and cache in India, so data stays in the country the privacy policy names. Internal services that are unreachable from the internet and refuse to start without their secrets. Deploys from CI without long-lived cloud keys. Logs that are redacted before they leave a service — verified in the stored copy rather than assumed from the code — so the observability layer cannot become the leak.
Data is encrypted in transit and at rest, with application-level encryption on the most sensitive third-party credentials. No analytics or advertising SDK ships in any client.
What the reviews found
Two full AI-assisted security reviews. The remediation is the receipt.
Both reviews were worked through, and the remediation went further than either had asked. A codebase-wide sweep found the error handlers that swallowed failures silently; the critical ones were fixed, and CI now fails the build if the count grows. Logs reach central logging with redaction intact, alerting is in place, and external uptime monitoring watches the service around the clock. The production schema drift described above was reconciled. Real-database integration tests and production-shape CI were stood up. A disaster-recovery restore was drilled and measured at 23 minutes 29 seconds, with full parity against production, rather than assumed.
One change matters most to a patient. Every drug-interaction check now records whether it completed, failed or was deferred, so a check that did not run can never be shown as "no interactions found."
What shipped from the remediation
Session rotation that detects a stolen token. A full forgot-password flow on web and mobile. Medication reminders that fire at the right local time wherever the server runs. Adherence that counts every scheduled dose rather than only the ones a person logs, so the number cannot improve just because someone stopped logging. Component tests for the web app on every pull request.
Planned
Broader caregiver permissions, and caregiver screens in the mobile app — caregiver management runs on the web today. The audit-log hash chain from decision 03. Crash reporting behind the redaction layer, background health sync, and reading documents beyond English.
Mobile is meanwhile ahead of web on integrations, carrying Apple Health and Health Connect that web does not.
In active development
The same consent model, extended to the people who look things up, write the records and hold them.
Knowledge Library
A condition-first reference: for a symptom or a diagnosis, the care approaches across systems of medicine side by side, with the strength of the evidence stated plainly for each — including when there is none. It holds reference content only, never a person's data, and it stays a library rather than a recommendation engine.
Vaulth for Doctors
Consent-first access for clinicians. A doctor asks; the patient sees who is asking and grants a scope and a duration; anything the doctor writes lands in the patient's own record; and the patient can revoke access and see every access afterwards.
Vaulth for Hospitals
Hospital documents reaching the patient's own record, and records requests that say who asked, why and on what basis — the same consent model, on the institution's side.
Both run as working applications ahead of joining the production platform.
The roadmap, tentatively
The longer-term direction is a trust layer for health data: records that stay portable, consent-driven and verifiable across patients, providers, insurers and public programmes, without control leaving the patient. It is sequenced in layers, and each waits on the one beneath it.
Some things wait on purpose: no marketplace for emergency care, no recommendation engine for alternative medicine, no AI that declares a doctor at fault or a test unnecessary, and no automated diagnosis.
Outcome
A production platform, built, verified and submitted to both app stores. The usage evidence comes next.
Everything above is build evidence. 227 endpoints, 74 tables, 938 mobile tests, a measured restore drill, two security reviews, a full queue migration and a from-scratch mobile rewrite. The privacy policy, terms and security pages are live at vaulthai.health, and the policy names the model production actually runs, checked against the running services rather than the source — which means the compliance phrasing described above is checkable without taking my word for it.
Version 2.0.0 of the mobile app has been submitted to the App Store and Google Play for review, launching in India first.
None of that is usage evidence. The measurement set is already chosen, and choosing it was itself a product decision: daily active users, session length and notification click-through are deliberately excluded, on the reasoning that a records vault optimised for those would be a worse vault.
No adoption figure appears here because there is not one yet. Every number on this page is build or census evidence; not one of them is a person trusting the platform with their records. This note stays until that changes.
"Live" means traffic is flowing — not that the code path exists and would work if someone provisioned it. Every claim on this page is held to that standard.
node.js · next.js · react · typescript · flutter · postgresql · redis · vertex ai · google cloud · dpdp-aligned · hipaa-aligned