One tap to the clinic

The new website and admin for Low Cost Clinic, Dr. Jyoti Puthran’s general-physician practice in Banashankari. Patients read about care and fees, book, ask and give feedback in four languages, with no login and no online payment. The clinic team runs every booking, message and page from one admin. Patient details are encrypted, and every look at them is logged.

A clinic website that does the clinic’s work

Low Cost Clinic is a general-physician and internal-medicine practice in Banashankari, Bengaluru, run by Dr. Jyoti Puthran. It serves local patients with diabetes, blood pressure, thyroid, cholesterol, fever and infections, and people looking for de-addiction or mental-health care.

Fees first, the clinic one tap away

Doctors are expected to announce their fees (IMC 2002), so every fee is on the Fees page and in each service page’s fees box before anyone books. Fees are paid at the clinic; there is no online payment.

• The phone number is shown as text and as a tap-to-call button.
• WhatsApp opens a chat with a ready message in the page’s language.
• The map is a picture with Tap to load map. Google Maps loads only when asked, so nothing from Google runs on a plain visit.
• On phones a bar at the bottom keeps Call, WhatsApp and Book in reach, and the header stays at the top.
• The footer carries the address, hours, the doctor’s registration number and council, every service, the legal pages and the emergency line.

A private page for every booking

Right after booking, and from every message, the patient reaches a page of their own. There is no account and no password.

• It opens after the last 4 digits of the mobile number used. Five wrong tries lock it for an hour.
• It shows the reference (such as LCC-4K7Q), status, visit type, date, time, fee, address and map, a masked mobile number, what to bring and the booking’s history.
• Add to calendar, fix a name or an email, change the contact preference or language, reschedule, cancel, turn reminders off, print or save as PDF.
• After the clinic’s cutoff the buttons give way to “Please call the clinic to make changes”.
• The link stops working 30 days after the visit. The page is titled only “Your booking”, and is never indexed or cached.

Feedback stays inside; notices go on top

Reading, downloads and search

One button sends every ready change

Edits are saved as drafts. Publish sends every change that is ready to the website, which is rebuilt in 1–3 minutes while staff keep working.

• A change that needs the owner (a fee edited by an editor, clinic settings) or a medical review (a page or an article) waits, and says why.
• Publish history shows each build and who asked for it.
• The public pages are plain files, so they stay up even if the database is down.

Twenty-three switches, each one instant

The owner can stop any feature, or show a language, at once: online booking, home visits, the enquiry form, banners, articles, resources, feedback, patient emails, WhatsApp buttons, staff digests, reminders, the generator, Hindi, Kannada, Marathi, analytics, teleconsultation and the sensitive visit types.

• Dependent switches turn off together: teleconsultation booking needs online booking.
• A switched-off endpoint answers “unavailable” with the clinic’s phone number. Existing bookings keep working.
• Users & roles and the audit log live beside the switches. At least one active owner is always kept.

Photos and PDFs shrink before they upload

• Photos are resized to 2,000 px and turned into WebP in the browser, which also drops the location data a phone camera writes into a picture. Alt text in each language.
• PDFs are compressed in the browser by Ghostscript (as WebAssembly, loaded only when a PDF is chosen), with their author and title data removed. A PDF per language, order and show or hide.
• The server trusts nothing it is sent: it checks the file really is WebP or a PDF, its size and dimensions, refuses PDFs with scripts, and spots duplicates.

Encrypted, field by field

• Names, phone numbers, emails, notes, comments and message text are encrypted (AES-GCM) before they are saved. The key lives only in Cloudflare’s secret store, never in the code or the database.
• Each value is sealed together with its place (table, column and row). Copied anywhere else it will not open, and the admin shows “[cannot be decrypted]” rather than the wrong person’s name.
• The database itself refuses plain text in those columns: a forgotten encryption fails loudly instead of storing a readable name.
• IP addresses and email addresses used for matching are kept only as salted hashes: enough to count, not to read.
• Weekly backups are encrypted before they are written.

Every change and every look, written down

• Every sign-in, change, opening of a patient record, export and publish writes an audit row: who, when, what, which record, and what changed.
• The audit row is saved in the same database batch as the change, so a change is never saved without its record.
• The log is append-only, kept for a year, and only the owner can read it.
• Each booking and home visit also keeps its own timeline of events, with old and new values encrypted.

Nothing in the address bar, the logs or the browser

• Web addresses carry a random code at most: never a name, a phone number or a condition. Admin searches are posted, so they never land in the address bar or history.
• Page titles stay generic. The booking page is “Your booking”.
• The browser keeps two things: the language and light or dark. The booking form holds details in memory only.
• Server logs hold no request bodies, no decrypted fields and no tokens. Request logging on Cloudflare is switched off, and errors never repeat what was typed.
• Analytics are cookieless and never run on booking pages; no outside script can read a form.
• The public site is built from published content only. A test proves the build cannot read a patient table.

Sensitive visits, neutral words

Mental health and de-addiction care need more than encryption: a calendar reminder on a shared phone, or a message on a lock screen, can say too much.

• “Consultation with Dr. Jyoti Puthran” is the only wording in messages, calendar files, web addresses, done screens and analytics.
• The WhatsApp message these pages prepare is neutral too.
• Admin lists say “Consultation”; the visit type shows only inside the record.
• Patients are asked whether a message may be left and whether WhatsApp is OK, and the answer is honoured: no WhatsApp button without it.

Kept for a year, backed up weekly, ready for the worst

The build cannot see a patient

The public site is built from the same database that holds the patients. So the build never reads that database directly.

1. Before every build, an allow-list of content tables is copied into an empty, migrated database in memory.
2. Every reader the pages use runs against that sandbox, which has no patient rows to give.
3. The build writes the pages, the translation files, the sitemap and structured data, and a content security policy with a hash for every script.

The rules, settled before the first line of code

The research output itself isn’t kept in the repository; this is what the requirement documents record from it, with their own caveat: “This is research, not legal advice.”

One phase per session, the same loop every time

The build was cut into 19 phases, each sized for one Claude Code session of about five hours. CLAUDE.md set the rules every session followed:

• Read first: the three documents, the plan, status.md, learnings.md and the phase’s design files.
• Stay in scope: anything extra goes into the notes for later.
• Test the rules that matter: every rule that protects patient data, prevents double booking or enforces a role.
• Finish clean: lint, typecheck, tests and build pass; the status and a learnings entry are written. An unfinished phase is marked In progress and finished first next time.
• The non-negotiables: no patient data in URLs, logs, titles, browser storage, analytics or errors; encrypted patient fields; a public build that reads only published content; neutral wording; no “cure”, “best” or testimonials.

Built, checked, and nearly open

Done All 19 phases built and checked; the preview is live at preview.lowcostclinics.in with its admin.

Before launch

• The domain’s DNS, the admin’s Access application with the staff list, Turnstile and the sending domain for email
• Data-processing terms accepted with Cloudflare and Resend
• The clinic’s last answers, so no [TBD] is left
• Reviewed Hindi, Kannada and Marathi texts, then each language switched on
• The release check against production, an uptime monitor, Search Console

For the clinic team

The staff guide is inside the admin (Help → User guide). The features list, technical details, runbook, deployment guide and security review live with the code.