Clinic Portal

Commercial project - delivered under NDA, client name withheld.

The brief that wasn't a brief

The starting point was a folder of Instagram videos and a handful of screenshots. That was the entire spec. No sitemap, no feature list, no idea of what "done" looked like - just proof that a clinic existed and treated patients well. Most agencies would have turned that into a five-page brochure site and called it a win. We turned it into an operating system for the clinic instead.

The problem with brochure sites

A gallery of media assets answers one question - does this place look legitimate? - and stops there. It doesn't let a patient check when a doctor is free. It doesn't let the front desk see who's booked for Tuesday. It doesn't let a doctor sync their day into the calendar app they already use. Every one of those gaps becomes a phone call, and phone calls don't scale past the first few dozen patients a month.

So the real brief was implicit: build the thing the media kit was standing in for.

What got built

A bilingual (Russian/English) clinic platform with three faces - a public marketing site, a staff admin panel, and a doctor-facing portal - all reading from one source of truth, all fully responsive down to a genuinely usable mobile experience rather than a shrunk desktop layout.

Public site. Every service, price, doctor bio, case study, and blog post is content-managed, not hardcoded - staff edit it in the admin panel and it's live within minutes. Patients book directly against real availability, not a static "leave your number" form.

Booking engine. Slot math runs independently in two places on purpose: a fast client-side calculation for the UI, and a database-level exclusion constraint plus a transactional booking function as the actual defense against double-booking. The UI can be wrong for a second; the database never is.

Admin panel. Staff manage the calendar, incoming requests, doctor schedules, and every piece of site content from one place. Role-based access is enforced twice - once in application logic, once in database row-level security - so a bug in one layer doesn't become a data leak.

Doctor portal. Each doctor gets their own calendar, availability controls, and a private ICS feed with a rotatable access token, so their schedule shows up natively in whatever calendar app - Google, Apple, Outlook - they already use. No app to install, no OAuth flow to configure.

Requests, not silence. Booking requests and cancellations trigger email notifications automatically, and the system is built to degrade gracefully: if the email provider isn't configured, it logs and moves on rather than blocking the booking itself. A notification failing is never allowed to look like a booking failing.

The hard part was never the UI

The hard part was making the guest-facing surface trustworthy without giving it any privileged access. Every public mutation - booking, cancelling, checking availability - goes through narrow, single-purpose database functions rather than direct table access. The anonymous role can call exactly the functions it needs and nothing else. Patient contact details used in cancellation and reminder flows are scoped per-appointment rather than pulled from a shared patient record, so an anonymous request can never fish for someone else's information.

Two layers, both required: row-level security in the database as the backstop, role checks in every server action as the first line. Neither is trusted to catch everything alone.

Built for handover, not for maintenance contracts

This was delivered as a turnkey product - no ongoing support contract, no infrastructure the client would need a developer to babysit. That constraint shaped every decision: no bespoke background services, no secrets required at runtime beyond what the hosting platform already manages, content and configuration editable by non-technical staff through the admin panel rather than by a developer through a deploy.

Results

• One codebase, three surfaces (public site, staff admin, doctor portal), one data model
• Real-time availability booking with database-enforced double-booking prevention
• Full bilingual content management - no hardcoded copy for anything staff should be able to change
• Per-doctor calendar sync via ICS, compatible with every major calendar client
• Fully responsive, mobile-first booking flow
• Zero-maintenance handover: the client owns and operates the product without a support retainer

Next.js (App Router) + TypeScript · Postgres with row-level security · server-side
rendering with incremental static regeneration for public content · transactional
database functions for anything that touches money or scheduling.