Ich habe kürzlich eine Website für eine selbstständige Massagetherapeutin erstellt, die ihre eigene Praxis betreibt. Es ist die Art von Projekt, bei dem die Anforderungen zwar leicht zu formulieren sind, man aber leicht Fehler macht, wenn man versucht, alles selbst zu lösen: eine ansprechende Startseite, eine Online-Buchung, die tatsächlich funktioniert, und eine Möglichkeit für die Inhaberin, ihren Terminplan und ihre Behandlungen zu verwalten, ohne mich jedes Mal anrufen zu müssen, wenn sich etwas ändert.

So haben wir uns für den Einsatz von Hapio entschieden, und warum es gut funktioniert hat.

Der Ausgangspunkt

Meine Kundin hatte bereits eine Facebook-Seite und nahm Buchungen über Messenger entgegen. Das funktioniert – bis es nicht mehr funktioniert. Doppelbuchungen, vergessene Termine, das manuelle Beantworten immer wieder derselben Fragen zu Preisen und Verfügbarkeit. Sie wünschte sich eine eigene Website, auf der Kunden direkt buchen können und auf der sie selbst Tage sperren, Öffnungszeiten anpassen und neue Behandlungen hinzufügen kann.

Das Wichtigste dabei: Sie ist Massagetherapeutin, keine Systemadministratorin. Alles, was wir entwickeln, muss für jemanden Sinn ergeben, der nicht in Datenbanken und APIs denkt.

Warum entwickeln wir das Buchungssystem nicht selbst?

I könnte haben ein maßgeschneidertes Buchungssystem entwickelt. Laravel, ein bookings Tabelle, Logik für freie Termine, Konfliktbehandlung, Pufferzeiten zwischen den Behandlungen, Umgang mit Ruhetagen, Sommerferien…

Aber genau das ist die Art von Code, die auf einem Whiteboard einfach aussieht, in der Praxis aber zu sechs Monaten voller Randfälle führt. Eine einzige Ressource (ein Therapeut), wiederkehrende Öffnungszeiten mit Ausnahmen, Pufferzeiten vor und nach jeder Behandlung, unterschiedliche Behandlungsdauern – das ist zwar keine Raketenwissenschaft, aber es isteine MengeCode, der für dieses spezielle Projekt keinen einzigartigen Mehrwert bietet.

Das übernimmt Hapio. Wir haben eine fertige API für Verfügbarkeit, Buchungen, Dienstleistungen und Terminplanung. So konnte ich mich auf das Wesentliche des Projekts konzentrieren: eine ansprechende Website und einen Buchungsablauf, der sich wieihr eigener anfühlt und nicht wie ein generisches Buchungssystem.

Die Architektur, für die wir uns entschieden haben

Wir haben eine schlanke Laravel-App als Wrapper für Hapio entwickelt. Stellen Sie sich das eher als „Frontend + Integrationsschicht“ vor, nicht als „vollwertiges Buchungssystem“.

Hapio ist zuständig für:

• Buchungen (anlegen, abrufen, stornieren)
• Leistungen/Behandlungen (Bezeichnung, Dauer, Preis, Pufferzeiten)
• Regelmäßige Öffnungszeiten (Mo–So)
• Einzelne Tage, an denen nicht gearbeitet wird (Feiertage, Krankheitstage usw.)
• Berechnung der verfügbaren Zeitfenster auf der Grundlage aller oben genannten Faktoren

Laravel ist zuständig für:

• Die Landingpage und die Buchungsoberfläche (Livewire)
• Verwaltungsbereich für Zeitplan, Dienstleistungen und Buchungsübersicht
• E-Mail (Bestätigung, Erinnerung, Stornierung – sowohl an den Kunden als auch an den Eigentümer)
• Sichere Stornierungslinks (HMAC-signiert, sodass Kunden sich nicht in die Buchung einer anderen Person einloggen können)
• Zwischenspeicherung verfügbarer Plätze (Redis)
• Webhook-Verarbeitung bei Änderungen an Hapio-Daten

Die Laravel-Datenbank enthält im Wesentlichen nur Admin-Benutzer, Sitzungen und Queue-Jobs. Es werden keine Buchungsdaten lokal gespeichert. Hapio ist die maßgebliche Quelle.

Das passt gut zu einem Unternehmen dieser Größe. Eine kleine lokale Datenbank, eine Redis-Instanz – es gibt nichts zu warten, was nicht unbedingt notwendig ist.

Der Buchungsablauf

Der Kunde durchläuft vier Schritte: Behandlung auswählen → Termin auswählen → Angaben eingeben → Fertig.

Die Behandlungen werden beim Laden der Seite aus Hapio abgerufen. Die Termine werden wöchentlich abgerufen – wir speichern sie intensiv im Redis-Cache, da es sich hierbei um die am häufigsten abgerufenen Daten handelt. Eine Wochenansicht, in der der Kunde bis zu zwölf Wochen im Voraus blättern kann.

Sobald die Buchung bestätigt ist:

1. Die Buchung wird in Hapio angelegt
2. Kundendaten (Name, Telefonnummer, E-Mail-Adresse, optionale Nachricht) werden als Metadaten zur Buchung gespeichert.
3. Es wird ein Stornierungslink generiert (HMAC-signiert mit einem geheimen Schlüssel, den wir kontrollieren)
4. Es wird eine E-Mail an den Kunden und den Eigentümer gesendet

Die Stornierung erfolgt über den signierten Link – eine Anmeldung ist nicht erforderlich. Wir haben eine 24-Stunden-Regel: Eine Buchung oder Stornierung ist nicht möglich, wenn die Frist kürzer ist. Die Regel wird in unserem Code zum Zeitpunkt der Auswertung angewendet, nicht im Cache, sodass sie konsistent funktioniert, selbst wenn der Cache noch nicht ungültig gemacht wurde.

Das Admin-Panel

Der Eigentümer meldet sich an und sieht vier Registerkarten:

• Buchungen– anstehende und vergangene, mit der Möglichkeit zur Stornierung
• Zeitplan– Klicken Sie auf einen Tag im Kalender, um ihn zu schließen oder zu öffnen
• Öffnungszeiten– der wöchentliche Zeitplan, Tag für Tag
• Dienstleistungen– Behandlungen hinzufügen, bearbeiten, deaktivieren

Alles läuft über die Hapio-API. Das Admin-Panel ist im Grunde ein ansprechendes Frontend, das auf dem Datenmodell von Hapio aufbaut. Wenn sie die Öffnungszeiten ändert oder einen Tag als geschlossen markiert, sendet Hapio einen Webhook, wir machen den Cache ungültig und erstellen die Zeitfenster im Hintergrund neu.

Es war etwas Arbeit nötig, um den Webhook-Ablauf stabil zu gestalten – Signaturüberprüfung, Idempotenz, Ausweichlösung mit vollständiger Cache-Leerung, falls etwas schiefgeht –, aber sobald alles eingerichtet war, hat es sich gelohnt. Die verfügbaren Zeitfenster werden schnell aktualisiert, ohne dass wir die API abfragen müssen.

Was gut funktioniert hat

Trennung der Aufgabenbereiche.Wir müssen uns nicht um die Buchungslogik kümmern. Hapio übernimmt die Konfliktlösung, die Pufferzeiten und die Terminplanung. Wir kümmern uns um die Benutzererfahrung und die standortspezifischen Aspekte.

Webhooks + Cache.Verfügbare Termine werden 24 Stunden lang zwischengespeichert. Wenn sich in Hapio etwas ändert (neue Buchung, Terminänderung, neue Dienstleistung) und ein Ereignis eingeht, machen wir den entsprechenden Cache ungültig und laden ihn neu. Kunden sehen die aktualisierten Zeiten, ohne dass wir bei jedem Seitenaufruf alles erneut über die API abrufen müssen.

Metadaten zu Buchungen.Kundendaten werden als Metadaten in der Hapio-Buchung gespeichert. Wir benötigen keine separate Kundentabelle. Für ein Ein-Personen-Unternehmen reicht das aus.

Stornierungslinks.HMAC-signierte Links in Bestätigungs- und Erinnerungs-E-Mails. Der Kunde muss sich nicht anmelden und sich auch keine Buchungsnummer merken. Wir überprüfen das Token serverseitig, bevor die Stornierung zugelassen wird.

Verwaltung ohne technischen Aufwand.Die Inhaberin kann ihren Terminkalender und ihre Dienstleistungen selbst verwalten. Ich muss nicht eingreifen, wenn sie einen Tag schließen oder eine neue Behandlung hinzufügen möchte.

Dinge, über die wir nachdenken mussten

SDK und Fehlerbehandlung.Wir nutzen das PHP-SDK von Hapio als Pfadabhängigkeit.Das SDK löst manchmal PHP-Warnungen aus, die echte Fehlermeldungen übertönen – wir haben die Aufrufe umschlossen und die Warnungen unterdrückt, damit API-Fehler tatsächlich durchkommen.

Die 24-Stunden-Regel.Die Geschäftsregel „mindestens 24 Stunden vor Buchung/Stornierung“ wird in unserem Code zum Zeitpunkt des Abrufs angewendet, nicht in Hapio. Das bedeutet, dass der Cache Zeitfenster enthalten kann, die dem Kunden nicht angezeigt werden – wir filtern diese bei der Rückgabe der Daten heraus. Einfach und vorhersehbar.

Eine Ressource, ein Standort.Die Konfiguration bezieht sich auf einen einzigen Standort und eine einzige Ressource (den Therapeuten). Sollte das Unternehmen auf mehrere Therapeuten oder Standorte anwachsen, müssten wir die Sache neu überdenken, aber für die derzeitige Konfiguration ist sie perfekt.

Zusammenfassung

Für eine kleine Massagepraxis, deren Inhaberin alles selbst verwalten muss, war Hapio die richtige Wahl. Wir haben kein Buchungssystem entwickelt – wir haben eine Website und eine Integrationsschicht erstellt, die Hapio so zugänglich macht, wie es zum Geschäftsmodell passt.

Laravel + Livewire für die Benutzeroberfläche und E-Mails. Hapio für die gesamte Buchungslogik. Redis für den Cache. Webhooks, um den Cache synchron zu halten.

Dank Hapio – und der Unterstützung durch KI – dauerte es etwa ein Wochenende, die gesamte Website von Grund auf so aufzubauen, dass sie sie tatsächlich für ihr Unternehmen nutzen konnte.

Es ist zwar nicht die komplexeste Architektur, die ich je entwickelt habe, aber sie gehört zu denen, die am besten zum Projekt passen. Und genau das ist es, was man will.

Entwurf. Verweise auf bestimmte Orte, Standorte oder Personen wurden bewusst weggelassen.