A medical clinic ran on a closed third-party booking system with no patient-facing way to book online, and no way to tell which ad or channel a new patient came from. I built a fast booking PWA in front of that closed system and an attribution layer that connects the first click to the booked appointment.
The problem
Booking lived entirely inside a closed vendor system. There was no public, mobile-friendly way for a patient to see real availability and book, and the vendor's API was never meant to be exposed to a browser. On the marketing side, the clinic spent on Instagram, YouTube, maps and messengers but could not answer the basic question every owner asks: which channel actually brings paying patients, and which ads pay back? Both gaps had a daily cost: a patient who cannot book at eleven at night is a patient someone else books in the morning, and an unattributed ad budget quietly keeps paying for channels that may never have produced a single patient.
The result
Patients book around the clock from a fast app, without the clinic exposing or replacing its closed vendor system — demand that used to wait for office hours now lands as confirmed appointments. And the owner finally sees which channel each patient came from, so marketing budgets follow booked patients instead of guesswork.
Below is how it's built.
Architecture
The system is a thin, fast patient app in front of a server-side proxy that does all the talking to the closed vendor system, plus an attribution layer that follows a patient from first touch to a confirmed appointment.
Patient PWA
A lightweight vanilla-JavaScript PWA — installs like a native app, loads instantly on mobile, and shows real availability. No heavy framework, so it stays fast on weak connections.
Server-side reverse-proxy
A Python/Flask layer that owns all communication with the closed clinic system: it handles authentication and token refresh, computes bookable slots server-side, and never lets the vendor's credentials or raw API reach the browser.
Booking flow
Availability, patient details and confirmation flow through the proxy as controlled, validated operations, so a booking made in the app lands correctly in the clinic's own system of record.
Attribution layer
Every visitor's first-touch source (Instagram, YouTube, maps, messengers) is captured and carried through to the booked appointment, so each patient can be traced back to the channel that brought them.
Key decisions & trade-offs
Decision — reverse-proxy on the server, not calls from the browser
The closed system's API and credentials must never touch the client. I put a Flask proxy in the middle that authenticates, refreshes tokens and computes slots server-side. The trade-off is an extra hop and more backend logic; in return the vendor integration stays secure, and I control validation, caching and rate-limiting in one place.
Decision — a vanilla-JS PWA over a framework SPA
For a single, focused booking flow that has to be fast on a phone, I chose a dependency-light vanilla-JS PWA instead of a framework build. The trade-off is writing more by hand, but the payoff is near-instant load, a tiny footprint and an app that installs to the home screen with no store friction.
Decision — attribution stitched end to end, not just page analytics
Rather than stop at page-level analytics, I carried the first-touch source all the way to the confirmed appointment. That turns marketing spend into a clear answer — which channel produced booked patients — instead of a vanity traffic number.
Decision — security treated as a first-class requirement
A patient-facing health app in front of a closed system needs to be hard to abuse: httpOnly server-side sessions, CSRF protection, anti-bruteforce on the booking endpoints, and XSS-safe DOM rendering throughout.