CarePoint

The problem

Booking a doctor usually means guessing which times are actually open, then paying separately, with no guarantee the slot has not been taken by someone else. Clinics and doctors, meanwhile, manage schedules, approvals and revenue across disconnected tools. CarePoint brings booking, payment and clinic operations into one platform for patients, doctors, clinic admins and super admins.

The approach

A Next.js client and a separate Express 5 REST API backed by PostgreSQL. Slots are computed on read from each doctor's weekly rules, leave days and existing bookings. A slot is held while the patient pays through Stripe Checkout, and four roles (patient, doctor, clinic admin, super admin) each get their own protected flows with ownership checked on every record.

Key decisions

• Let the database arbitrate double bookings with a partial unique index on (doctorId, slotStart) for active statuses, instead of row locking, so a new code path cannot forget the check. A test fires two simultaneous bookings for one slot and asserts exactly one succeeds.
• Made payment confirmation independent of a single webhook. The Stripe webhook, a status-page sync and a 10-minute reconciliation sweep all use the same conditional update, so they are safe to run in any order or twice.
• Made refunds refund-first and idempotent, using a Stripe idempotency key and updating the database only after Stripe succeeds, so an appointment can never be cancelled without returning the money.
• Enforced authorization in the query itself (owner in the where clause), read roles from the database on every request, and shaped responses with select so private fields never leave the server.
• Stored all times in UTC and interpreted them in the clinic's time zone, so a late-night slot never lands on the wrong date.

The outcome

Two simultaneous bookings for one slot are tested to produce exactly one winner, backed by a database-level unique index. Patients can pick a slot, pay and manage appointments, while doctors, clinic admins and super admins run schedules, approvals and reports through separate, protected flows. The server is covered by a test suite that runs against a real PostgreSQL database, including simultaneous booking, cross-user access, webhook ordering and refund failure cases, with CI running lint, build and tests on every push.

What I would build next

• Always-on hosting or an external scheduler so reminder and payment-sweep jobs do not depend on a free-tier instance staying awake.
• Emails for clinic and doctor approval decisions, and a way for rejected applicants to reapply.
• End-to-end tests of the booking flow, plus structured logging and error tracking.