Venevio.

Ein reserviertes Tischpaar, das nicht erscheint, kostet doppelt: Der Tisch bleibt leer, und die Gäste, die man dafür abgewiesen hat, sind auch weg. Am Freitagabend um 20 Uhr trifft das härter als am Dienstagmittag — und bei acht Personen härter als bei zweien.

Die naheliegende Antwort wäre, für jede Reservierung eine Kaution zu verlangen. Das funktioniert in der Praxis nicht: Wer für zwei Personen am Dienstag zwanzig Euro hinterlegen soll, bucht woanders. Die Lösung muss also unterscheiden können — nach Gästezahl, Wochentag, Uhrzeit und danach, wie sich dieser Gast in der Vergangenheit verhalten hat.

Genau das war die Produktentscheidung: nicht das hundertste Reservierungsformular, sondern ein Regelwerk, das der Betrieb selbst einstellt und das im Normalfall unsichtbar bleibt.

Jeder Betrieb hinterlegt eine Regel: ab wie vielen Gästen, an welchen Wochentagen, in welchem Zeitfenster, wie viel pro Person — und einen Deckel nach oben. Eine Buchung wird gegen diese Regel geprüft, bevor überhaupt nach einer Zahlung gefragt wird. Fällt sie durch eines der Kriterien, ist keine Kaution fällig und der Gast merkt vom ganzen System nichts.

Der Deckel ist wichtiger, als er aussieht. Ohne ihn zahlt eine Zwölfergruppe 120 Euro Kaution und bucht nicht — obwohl gerade große Gruppen das eigentliche Risiko sind. Mit Deckel bleibt die Kaution ein Signal, keine Hürde.

Nach dem Besuch läuft die Rückerstattung von selbst: Ein täglicher Cronjob sucht bezahlte Kautionen zu vergangenen Terminen, erstattet sie über Stripe zurück und schickt eine Bestätigung. Bleibt die Reservierung als No-Show markiert, verfällt der Betrag — auch darüber wird der Gast informiert. Der Betreiber muss in beiden Fällen nichts tun.

Damit „hat schon dreimal nicht abgesagt" überhaupt bewertbar ist, führt das System eine Historie pro Gast — betriebsübergreifend. Das ist datenschutzrechtlich der heikelste Teil des Produkts, also liegt in dieser Tabelle keine Telefonnummer und keine E-Mail-Adresse im Klartext:

Nachgeschlagen wird über den Hash der eingegebenen Kontaktdaten. Wer die Datenbank liest, sieht Zahlen und Hashes — aber keine Liste von Personen. Daraus entsteht beim Buchen eine Einstufung in low, medium oder high, die auf der Reservierung gespeichert wird. Steht die Regel auf high_risk_override, kann diese Einstufung eine Kaution auslösen, die sonst nicht fällig wäre.

Wer wiederholt nicht erscheint, landet auf einer Sperrliste. Das ist die Sorte Funktion, bei der die Umsetzung mehr über Verantwortung entscheidet als über Technik — deshalb Hashes statt Klartext und eine Einstufung, die begründbar bleibt, statt einer undurchsichtigen Punktzahl.

Der Stack: Next.js 16 mit React 19 auf Vercel, Oberfläche mit Tailwind und Radix-Bausteinen, Daten und Authentifizierung über Supabase (Postgres mit Row Level Security) plus NextAuth, Zahlungen über Stripe inklusive Connect und Webhooks, E-Mails über Resend, Fehlerüberwachung mit Sentry. Rund 257 JavaScript-Dateien, 70 API-Routen, 62 SQL-Skripte.

Regeln in Daten statt in Code. Kautionsbedingungen, Tariffunktionen und Öffnungszeiten liegen als Zeilen in der Datenbank, nicht als Bedingungen im Anwendungscode. Ein Betrieb, der freitags ab vier Personen kassieren will, braucht damit keine Anpassung im Code — nur einen anderen Datensatz. Der Preis: mehr Prüflogik zur Laufzeit und Migrationen, die man sauber schreiben muss.

Ein Cronjob statt vieler. Fünf separate Aufgaben wären einzeln einfacher zu verstehen. Ein gemeinsamer Lauf ist dafür an einer Stelle nachvollziehbar, wenn nachts etwas schiefgeht — bei einem Projekt, das eine Person betreibt, zählt das mehr als saubere Trennung.

Kautionen über Stripe Connect statt über das eigene Konto. Der bequemere Weg wäre gewesen, das Geld selbst einzuziehen und weiterzuleiten. Das hätte aus dem Projekt ein Treuhandgeschäft mit allem gemacht, was daran hängt. Über Connect gehört das Geld dem Betrieb — die zusätzliche Einrichtung pro Kunde war es wert.