Booking software that
runs itself
Online booking, automated reminders and post-visit follow-ups for clinics. I designed and built the whole thing, from the booking page to the scheduler that sends the reminders.
Nobody has this page open. The scheduler wakes on its own, works through what is due, and moves each appointment on.
What a clinic gets
Each clinic gets its own booking link, its own opening hours and its own list of services. Clients pick a slot without phoning anyone, the confirmation goes out immediately, and the reminder goes out two days before. After the visit, a follow-up sequence asks for a review and invites a rebooking. I wrote every layer of that, the interface, the API, the database and the jobs that run between them.
Why it needed a back end
This is the only one of my projects that is a system rather than a site. The back end exists because of four things that cannot happen in a browser.
A free slot has to be computed
The opening hours for that weekday, the days the clinic is closed, how long the chosen service takes, and every appointment already on the books. A free slot is what is left after all four, and it is only correct if the server works it out.
A reminder fires two days before the appointment
That cannot live in a browser tab. A scheduler wakes on its own, hands the work to a queue, and a worker sends it. A send can fail with no one watching it, so failures are retried.
An appointment's status moves on its own
Pending, reminded, confirmed, completed. Every transition is written to a history table as it happens, so the record of what the system did outlives the session that started it.
Every clinic has to be sealed off from the others
One deployment serves many clinics, each with its own link, services and hours. Every protected request resolves which clinic the caller owns and scopes the query to it. Getting that wrong would leak one clinic's patient list into another's dashboard.
What actually runs
Six containers. The Nuxt front end proxies to the API rather than calling it from the browser, so the session cookie never leaves the server. Postgres holds the data and Redis is the queue, with two Celery processes behind it, a worker that sends and a scheduler that decides when. Nothing starts until whatever it depends on reports healthy.
Migrations, tests and rate limits
Schema changes go through migrations rather than being applied by hand, so the database can be rebuilt from nothing and arrive in the same place. Ten test suites cover the routes, the slot generation, the scheduling and the rate limits, with component and composable tests on the front end. The public endpoints sit behind rate limiting, because anyone on the internet can reach a booking form.
The stack
- Nuxt 4
- Vue 3
- TypeScript
- Tailwind 4
- PrimeVue
- Firebase Auth
- FastAPI
- Python
- SQLAlchemy
- Alembic
- PostgreSQL
- Redis
- Celery
- Docker
That list includes PrimeVue, which this page does not use. The components you're looking at are rebuilt by hand in Tailwind. Carrying a whole component library here to draw six cards would be a strange trade.
So why can't you buy it?
Because the next step is legal, not technical. Handling other clinics' patient data means contracts and data processing agreements, and that is a lawyer's job rather than a weekend's. The software is deployed and running. The paperwork is the missing part.
Deployed, and parked on purpose.