Das erste Buchungs-Widget war hart verdrahtet. Zeiten, Servicegebiete, Behandlungen, alles hardcoded. Das reicht für einen Smoketest und die ersten Wochen Betrieb. Ab einem bestimmten Punkt kippt es. Spätestens, wenn eine zweite Therapeutin dazukommt, mit anderen Arbeitszeiten, anderen Gebieten und eigenen Urlaubstagen. Und wenn manuell eingetragene Termine sich mit gebuchten Slots überschneiden, ohne dass das System das weiß.

Ein Backend, das die operative Realität sauber abbildet. Flexible Schichtplanung pro Tag statt fester Schichten. Eine zentrale Wahrheit über alle Termine, egal ob online gebucht oder manuell eingetragen. Kollisionsprüfung, Puffer zwischen Terminen für Anfahrt, Vorlaufzeiten. Alles berechnet aus den Daten, nicht aus statischen Arrays.

Supabase als Datenbasis, mit PostgreSQL-Funktionen für die eigentliche Logik. Slot-Berechnung, Kollisionsprüfung und Buchungsanlage passieren in der Datenbank, atomar und konsistent. Ein Cloudflare Worker sitzt als dünne API-Schicht davor, regelt CORS und Rate Limiting. Das Widget bleibt bewusst dumm, es ruft nur APIs auf und stellt dar. Gebaut in 15 Sessions mit Claude als AI-Pair-Programmer. Keine Tickets, keine Sprints, keine Übergaben. Ein fortlaufendes Gespräch über zwei Wochen, in dem Problem, Architekturvorschlag, Business-Kontext und Code-Generierung in einer Feedback-Loop liegen.

Das System läuft. Es trägt die heutigen Anforderungen und die, die für die nächsten Monate absehbar sind. Die wichtigste Erkenntnis liegt nicht in der Technik, sondern in der Art, wie sie entstanden ist. Vor zwei Jahren hätte ein vergleichbares Setup zwei Fulltime-Entwickler, einen Product Manager und rund zwölf Monate gebraucht. Die Feedback-Loop ist kürzer geworden, nicht weil man schneller tippt, sondern weil der Kontext nicht mehr verloren geht.