Marsa Dental & Orthodontics

A dental practice does not run like a GP's. The bill is decided in the chair, tooth by tooth. Braces are not a visit but eighteen or twenty-four of them over two years, paid in instalments that drift if nobody watches. A blood thinner or a penicillin allergy matters before the needle, not after. And the patient leaves with instructions they will have forgotten by the car.

The ask was a dentist's seat on the Marsa clinic system — booking, reception, the waiting-room screen, the doctor's desk and the owner's numbers, all live on one database — without breaking the three physicians already on it, and at the standard a dentist would trust with a working day.

It is a demo, so a stranger has to be able to sit in every chair in a minute. Everything in it is invented and it starts over every day; the clinic it describes is not.

• Visit types per doctor: the dentist offers an exam, an orthodontic session and a cleaning online; fillings, root canals, extractions, braces and whitening are booked by the clinic — each with its own length, and a price or “after the exam”
• An FDI tooth chart in the dentist's view, with tools for decay, filling, root canal, missing, crown and implant, carried over from the last visit
• Today's work recorded tooth by tooth with its price; the total is what reception collects, the moment the dentist records it
• Medical alerts on the patient — blood thinners, anaesthetic or penicillin allergy, diabetes, blood pressure, pregnancy — beside the name in every queue, with a warning when today's work or a drug conflicts
• Braces as a case: session N of M, the wires on now and last time, the total, paid and owed; the next session booked in one click, four weeks on
• At the desk, a session plus an instalment, never more than the case owes
• For the owner, revenue per doctor or for the dentist alone, and the braces patients overdue for their session
• A5 after-care sheets in Egyptian Arabic after an extraction, a filling or whitening; a waiting-room screen for one to four rooms that calls each number aloud

browser checks on a dental visit, at phone width

32browser checks on a dental visit, at phone width

automated tests, the dental ones included

41automated tests, the dental ones included

procedures priced on the chart

11procedures priced on the chart

click to book the next session

1click to book the next session

Anyone can list a stack. The useful part of a case study is the calls that had a real alternative — so each of these says what the tradeoff was, not just what was chosen.

1. 01

   Visit types belong to the doctor

   Each doctor carries their own list of visit types — length, price or none yet, and whether patients may book it online.

   “Exam or follow-up” fits a physician and nothing else. A filling takes forty-five minutes and an orthodontic session twenty, and free times are cut to the length of the visit asked for, so a root canal is never offered a gap only a check-up fits. Work that needs an exam first is booked by the clinic, not the public.

   Tradeoff · The list lives in a JSON column, which the database checks less strictly than a table. The old exam and follow-up columns are still written, so the version before it kept working while the new one was rolling out.

2. 02

   The bill is what was done

   The work recorded on the chart, tooth by tooth, is the visit's price; reception sees it the moment the dentist records it.

   At a dentist the price is not known at booking — an exam turns into a filling and an X-ray. Making the sum of procedures the visit's fee means nobody retypes it at the desk, and the owner's revenue is what was collected, not what was booked.

   Tradeoff · Prices come from a fixed list the dentist can override line by line. A clinic would want its own price list and a rule for discounts before going live.

3. 03

   Braces are a case, not a visit

   An orthodontic case holds the number of sessions and the interval; each session joins it and takes its number when it actually happens.

   Numbering at booking went wrong in testing: a session booked for next month took number four, and the patient who walked in today got five. Counting what happened keeps “session 2 of 24” true however early or late the patient comes. The case's money adds up across its visits, so the desk can take an instalment on any session and is stopped at what the case owes.

   Tradeoff · One open case per patient, and no treatment-plan builder: a plan with quotes for several visits is the next piece.

4. 04

   Alerts live on the patient

   Medical alerts are kept on the patient, not the visit, and shown beside the name in every queue and on every sheet.

   An allergy ticked today must be there next month, at the desk as much as in the chair. When today's work or a drug conflicts with one — a blood thinner before an extraction, a penicillin allergy and an antibiotic that contains it — the sheet says so in a sentence, in red.

   Tradeoff · The warnings are a short list of pairings, not a drug-interaction database; they remind, the dentist decides. They need a dentist's review before real use.

5. 05

   The chart is the dentist's view

   Teeth are numbered FDI and drawn as the dentist faces the patient — the patient's right on the left — always left to right, inside a right-to-left page.

   FDI is what dentists in Egypt write, and a chart that mirrored with the page's direction would put tooth 18 where 28 belongs. Each tooth is drawn by its kind, with its roots, so a molar reads as a molar at a glance and the marks sit where the work is.

   Tradeoff · It is drawn for the dentist, not the patient; a patient-facing view would want the mirror image and plain words.

The dentist arrived on a system already live. The migration only adds — new tables, new columns with defaults — so the version before it carried on serving while the new one built, and the physicians' booking, desk and sheets kept every test they had.

It was checked the way a patient would meet it. A script books the dentist on a phone-width browser, follows the booking on a second phone, checks in at the desk, calls the number, listens to what the waiting-room screen says, marks the chart, records a filling, prints the prescription and the after-filling sheet, books the next session, collects the money and confirms the owner's revenue moved by exactly that. All 32 checks passed against the live deployment, and the 52 across every role still did.

The film was made from the same site. Each screen was recorded through the browser's own screencast with its timestamps, a sharp still was taken whenever the page was at rest, and the cut was assembled frame by frame, the cursor drawn from the log of real clicks. The music was synthesised for it, bar lines on every cut.

Scope discipline is part of the work. Each of these was considered and cut for a stated reason.

X-rays and photos

Images need storage, consent and retention rules. The chart records an X-ray as a procedure; the image itself is not kept.

Treatment plans and quotes

Work across several visits is recorded visit by visit. A plan the patient approves up front, with a quote, is the next step.

Lab work

Crowns and appliances from a lab have their own dates and costs; nothing tracks them yet.

Reminders by message

The owner's list shows who is overdue; reaching them is a call from the desk. SMS or WhatsApp reminders cost per message and belong to a real clinic's launch.

Staff accounts

Every seat opens with one click by design. A clinic using it for real needs named users and a record of who did what.

Everything in the demo is invented: the clinic, the dentist, the patients, the phone numbers and the prices. The alert pairings and the after-care sheets were written for the demo and have not been reviewed by a dentist. Scheduling, the queue and the dental records are covered by 41 automated tests, a dental visit by 32 browser checks and every role by 52, all passing against the live site on 22 October 2026. The interface is Arabic only, and the spoken call needs a device with an Arabic voice. No dental clinic has used it.