Healthcare

Appointment booking for a dental clinic

A booking system for a dental clinic with four chairs. Patients pick a treatment type and a slot, the clinic sees a day view per chair, and the patient gets an SMS reminder the day before. Reception can move an appointment without phoning anyone.

Automatically generated draft

Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.

Section 01 · What has to work

For the product to launch, a patient must be able to book an available time slot for a specific treatment, and the clinic must see that booking appear instantly on the correct chair's schedule.

Section 03 · Screens

Every screen, and what it is for.

  • ›Patient Booking — Patient picks a treatment and time slot, then confirms their booking. Must be instant: showing available slots.
  • ›My Appointments — Patient views their upcoming and past appointments. Must be instant: loading their personal appointment list.
  • ›Clinic Day View — Staff sees appointments for all four chairs on a single day. Must be instant: switching between calendar days.
  • ›Appointment Editor — Staff clicks a booking to view details or move it to another time/chair. Must be instant: opening the editor panel.
  • ›Treatment Management — Staff defines treatment types, their durations, and costs. Must be instant: saving changes to a treatment.

Anything not on this list is not in version one. That is what keeps a fixed price fixed.

Section 04 · The data model

What it stores, and who can read a row.

user

uuid id, text name, text phone_number, timestamptz created_at, enum('patient', 'staff') role

Access · Staff can read any user. A patient can only read their own row.

treatment_type

uuid id, text name, int duration_minutes, numeric(10,2) cost, boolean is_active

Access · All authenticated users can read. Only staff can create or modify.

appointment

uuid id, uuid patient_id, uuid treatment_type_id, timestamptz start_time, int chair_id, text notes, timestamptz reminder_sent_at

Access · Staff can read all appointments. A patient can read their own.

Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.

Section 05 · States

scheduled → completed | cancelled_by_patient | cancelled_by_clinic | no_show

Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.

Section 06 · Where this breaks

What bites products like this one.

Two users book the same final slot, causing a double booking that the clinic must resolve manually.

Use database-level transaction locking on slot creation to ensure appointment writes are atomic and serialized.

The third-party SMS service fails, so reminders are not sent and no-show rates increase.

Implement a background job with retries for SMS sending, and alert staff on persistent delivery failures.

A patient moves an appointment just as staff is moving the same one, causing data corruption.

Use a versioning field on the appointment record to detect and prevent concurrent edits from overwriting each other.

Section 08 · Deliberately left out

What version one does not do.

  • ×Patient-facing self-service rescheduling and cancellation — requires complex rules. Staff can handle changes by phone for v1.
  • ×Online payments for treatments — introduces refund complexity for cancellations. Bill patients at the clinic after the initial launch.

This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.

Still open

What we would ask before quoting.

  • Which provider will send SMS reminders, and will the clinic provide its own account or will we manage it?
  • When moving an appointment, what business rules prevent placing it in an occupied slot or outside clinic hours?
  • Will we need to import existing patient records and future appointments from another system?

Your product, not this one

Get this written for what you are actually building.

Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.

Next step

Find out if your idea fits in 10 working days.

Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.

NDA available on request