Clinetta

The need

A physiotherapy clinic with one doctor, two secretaries and up to 24 appointments a day was running on paper and one Word document per patient. That caused four daily problems:

• No shared schedule. The two secretaries could not see the day at a glance or avoid conflicts.
• Slow rescheduling. Cancellations and no-shows are frequent, and each one was handled by hand.
• Unstructured history. Each patient had one history and plan for life, with no separation between treatment cases and no diagnosis category.
• No visibility. The doctor had no figures on revenue, patient volume, case mix or cancellations.

What I owned

I was the product owner. I analysed how the clinic worked, wrote and prioritised the requirements with MoSCoW, defined every KPI, directed the build through Claude Code, and tested and approved each milestone before the next one began.

The solution

Clinetta is one web application used by the doctor and the front desk at the same time. Three ideas make it more than a digital calendar:

• Two people, one calendar. Changes appear on every open screen immediately, and the server refuses a second booking of the same slot.
• The system follows up. A no-show or a doctor’s absence creates a call-back task, so patients are not forgotten.
• Numbers without manual work. Revenue, attendance and case mix are calculated from daily use, with no separate reporting step.

Key modules

Agenda

Week and day calendar with cards coloured by status. Booking checks working days, opening hours, closures, absences and other appointments, then offers the two nearest free slots if the time is taken.

Patients

One permanent file per patient, split into treatment episodes. Session history grows automatically after each closed session, alongside payments and attachments.

Alerts

The secretaries' call-back list for no-shows and appointments hit by an absence. Rescheduling or cancelling removes the alert, so the counter always shows the work left.

Analytics

Ten monthly indicators compared with the previous month, plus case mix and long-term trends. Any month exports as a PDF summary and an Excel file.

How it was built

The build ran in 11 milestones during October 2026. Each one was tested automatically and in the browser, then approved by me before the next began. The specification defines 46 features, 39 automations and 21 business rules, and the code and tests refer back to those IDs, so any behaviour can be traced to its requirement.

Four decisions shaped the system:

• The episode as the central idea. A patient keeps one file and can have several treatment cases over time, which solves the single-history problem of the Word files.
• No double booking, even at the same instant. The clinic is locked during a booking and a database constraint forbids overlaps, so of two simultaneous bookings one is refused.
• KPIs with agreed definitions. Only patient cancellations count in the cancellation rate, and a no-show still counts after it is rescheduled.
• Ready for more clinics. Every business table carries a clinic identifier and modules can be switched per clinic, so new specialties come through configuration and not through copies of the code.

Results

• A complete application covering all six modules: shell, agenda, patients, alerts, analytics and settings.
• 886 unit and API tests plus 178 end-to-end browser tests, covering the rules, the permissions and full clinic scenarios.
• 21 database tables and 74 documented API operations.