Before Nivora could automate a clinic, I had to define what the clinic is allowed to configure — and what it is not allowed to break. When I started building Nivora, I didn't want the operational workflow to become a collection of hardcoded screens. A real clinic has its own appointment types, fees, procedures, medicines, operating rules, payment methods, cancellation reasons, revisit patterns and receipt requirements. But changing those business details should never change the underlying workflow or security boundaries. So I built the foundation first. What:- Clinic configuration Clinic profile and identity Location, contact and timezone Operating rules Check-in and late-arrival windows Receipt and invoice presentation Business Masters Appointment types & consultation fees Dental procedures & default fees Medicines Dosage, frequency, route and duration choices Payment methods Consultation outcomes Revisit reasons Cancellation, no-show and waiver reasons Access foundation Authentication Roles RBAC Permission boundaries Protected workflow transitions Why:- The important distinction is: Business configuration is editable. Workflow integrity is protected. A clinic should be able to change its business vocabulary without being able to bypass the rules that protect appointments, clinical records, payments, permissions and state transitions. The Masters therefore provide safe business choices — not workflow code. When:- I built this foundation before the deeper operational workflows because everything that comes later depends on it. The booking flow needs appointment types and fees. Reception needs operating rules, cancellation/no-show reasons and check-in policy. Consultation needs outcomes and clinical configuration. Treatment needs verified procedures. Prescription needs medicines and instruction choices. Payments need defined payment methods and financial configuration. Instead of hardcoding these dependencies into every module, the foundation provides a controlled source for them. How:- The architecture separates configuration from authority. A clinic can configure what it offers and how it presents itself. Staff can only perform actions allowed by their role. Critical state transitions remain server-controlled. Clinical records remain protected. And changing a Master value doesn't rewrite the underlying workflow. This means the same operational model can serve a different clinic configuration without turning the system into a different application every time. What this changes in a real clinic day Morning: The clinic's operating rules determine when reception can check patients in. Booking: Available appointment types and configured fees drive the booking experience. Reception: Staff work within their permitted actions instead of having unrestricted access to clinical operations. Consultation: The dentist works with controlled clinical workflows and configured procedures/outcomes. Treatment: Verified procedures and treatment rules feed the next operational step. Prescription: Medicine and instruction choices come from controlled Masters, while clinical authorship stays with the dentist. Payment & receipt: The system uses the existing financial foundation rather than creating disconnected billing logic. The clinic can change its business configuration. The system still protects its operational integrity. That's the foundation I wanted before continuing deeper into Nivora. Not just a booking interface. A configurable clinic operating system built around a protected workflow. Progress update — Foundation → Configuration → Controlled Operations #lovablechallenge #lovableapp #lovableexperts Head of Product @Contra! Social @ Lovable Design @ Lovable @Lovable