A dental clinic, run as one system. 

Live KPIs for bookings, status mix, average per day, top service and revenue. Revenue-over-time and bookings-per-day charts can be filtered by branch and date range (today, week, month, custom).

Aggregation pipelines run server-side per tenant, with the clinic always as the first query key. One endpoint feeds every tile, so the numbers never disagree with each other.

Owners are usually the lead dentist too. They need one glance between patients, not a report builder.

Bookings in list and calendar views with status flow (open → confirmed → finished / cancelled). The public wizard goes Your info → Branch → Services → Doctor → Confirm. Reminders go out 24 hours and 1 hour before.

Slots are duration-aware: a 60-minute service blocks two 30-minute slots. Schedules inherit doctor → branch → clinic settings, and vacations and conflicts are flagged. A partial unique index in MongoDB is the final race guard, proven with real concurrent HTTP tests.

Double booking is the fastest way to lose a clinic's trust. Enforcing it in the database, not only in app code, means two receptionists clicking at the same moment can't both win.

Patient tabs for overview, bookings, clinical and billing. The FDI tooth chart covers adult and pediatric teeth, with diagnosis, treatment, image, periodontal and multi-select modes. It sits alongside treatment plans, X-ray attachments, notes, materials, visit history and tooth history.

The clinical visit is the anchor document everything hangs off. Tooth history is append-only, and a codebase-wide grep for update or delete calls returns zero matches. Attachments live in private storage, never on public URLs.

A clinical chart is a legal record. With an append-only timeline nothing is silently overwritten, and the chart can be rebuilt as it stood on any past visit.

Invoices with partial-payment states, expenses, cost of goods, and a summary of billed, collected, outstanding and net per branch and period. Invoices export to PDF.

The client never sends totals: every amount is computed on the server from line items. Payments are append-only ledger entries, so corrections are new entries, not edits. PDFs are rendered server-side with PDFKit.

When money numbers come from exactly one place, there's nothing to reconcile, and every number on the screen can be traced back to the entries behind it.

An item catalog by kind and category, stock levels per branch with low/out alerts, a supplier registry, and stock requests between branches.

Stock changes only through append-only movements. Completing a treatment records its material consumption. Stock-request fulfilment is atomic and proven under concurrent requests.

Chains move stock between branches every week. Atomic transfers mean stock can't vanish in transit or be counted twice.

A floating assistant panel available on every dashboard page. It answers questions about services, bookings, revenue and trends.

The LLM (Gemini, behind a provider adapter) can only answer through scoped tool calls: list_services, count_bookings, revenue_summary and top_services. Tools run under the clinic's tenant scope, the context structurally excludes patient health data, and each question is written to the audit log.

Owners ask questions; they don't open reports. Tool calls keep answers grounded in the clinic's real numbers instead of invented ones.

20+ permission groups, a role editor, branch restrictions and an invite flow. Doctors get a narrowed “My Day” portal. A 180-day audit log records who did what, where and when.

Permission checks sit on every route, and branch access goes through shared helpers instead of ad-hoc checks. A doctor is a team member linked to a Doctor record, deliberately not a fifth auth system. The audit log is append-only and can't be switched off by plan.

Accountability is what lets an owner hand the front desk to someone else, and what answers “who changed this invoice?” in seconds.

Starter, Professional and Clinic Chain plans with limits on branches, doctors, staff, patients and bookings per month. The clinic sees its usage, renewal date and enabled modules.

A single feature-flag seam. Six core modules are on by default; eight upsell modules (finance, inventory, loyalty, CRM, chat, AI, website builder, custom domain) are off by default. Flags are enforced in the API and the navigation alike, with per-clinic overrides from the operator console.

Every new module ships turned off and gets enabled per plan. Packaging and pricing become a product decision, not an engineering task.

A public clinic page with branches, services and doctors. The owner sets brand colors and English / Arabic / bilingual content, works in a draft, then publishes. Custom domains are supported.

Next.js middleware rewrites unknown Host headers to /c/<host>, so a custom domain serves the same app. Domain ownership is verified with a DNS TXT record and a scanner catches drift. Owner content renders through a safe markup renderer.

For a small clinic the website is the lead-generation engine. Bookings land directly in the system, not in a WhatsApp chat someone forgets to answer.

The operator console covers clinics, the activation-request queue, the plan and feature editor, domains, a support inbox and monitoring: MRR, bookings, request volume, 4xx/5xx errors, rate-limit trips and auth-failure clusters.

The console has its own auth system, cookie type, Axios instance and React context, so it is fully separate from clinic auth. Metrics are sampled every 60 seconds in-process, and failed-login clusters by IP are surfaced for review.

Support and sales run through this screen. Because platform auth is separate, a clinic user can never gain operator access.