Clavenda: Wie wir für zwei Hotels die Software gebaut haben, die es am Markt nicht gab

Hotels zahlen jeden Monat vierstellige Beträge für Software, die sie zu einem Bruchteil nutzen. Die Systeme sind vor zwanzig Jahren entstanden, haben jede Branchenanforderung seither als Modul angebaut und rechnen heute pro Zimmer, pro Arbeitsplatz, pro Schnittstelle ab. Wer ein Haus mit vierzig Zimmern führt, bezahlt die Komplexität einer Hotelkette mit.

Für einen Kunden mit zwei Häusern haben wir diesen Zustand nicht optimiert. Wir haben die Software neu gebaut. Das Ergebnis heißt Clavenda, läuft seit dem 1. September 2026 im Echtbetrieb und ist inzwischen ein eigenes Produkt.

Die Ausgangslage: Zwei Häuser, ein Altsystem, eine Rechnung ohne Gegenwert

Der Kunde betreibt zwei Beherbergungsbetriebe unter einer Gesellschaft: ein Privathotel und ein Apartmenthaus im Nachbarort. Beide Häuser liefen auf derselben etablierten Hotelsoftware, beide mit derselben Erfahrung.

Das System konnte alles. Reinigungsplanung, Tischreservierung, Kassenmodul, Kundenbindungsprogramm, Modulkatalog über dreißig Positionen. Genutzt wurden davon der Belegungsplan, die Buchungserfassung, die Rechnungsstellung und der Export an den Steuerberater. Der Rest war bezahlte Oberfläche.

Dazu kamen die typischen Reibungsstellen. Zwei Betriebe, deren Buchhaltung sauber getrennt sein muss, aber ein Rechnungsnummernkreis, den man mit Disziplin auseinanderhalten musste. Portalbuchungen, die morgens abgetippt wurden. Eine Buchungsstrecke auf der eigenen Webseite, die den Gast am Ende doch zu Booking.com schickte. Und ein Supportvertrag, bei dem eine Rückfrage drei Werktage dauerte.

Die eigentliche Zahl steht aber woanders. Bei 15 bis 25 Prozent Provision auf jede Portalbuchung entscheidet nicht die Softwaremiete über die Wirtschaftlichkeit, sondern der Anteil an Direktbuchungen. Eine Software, die die eigene Buchungsstrecke schlechter macht als die von Booking.com, kostet ein Vielfaches ihres Preisschilds.

Das Problem im Detail: Warum Standardsoftware hier nicht passt

Wir haben vor der Entscheidung den Markt geprüft, in zwei Richtungen. Oben stehen die Cloud-Anbieter der neuen Generation: modern gebaut, gut bedienbar, aber auf Häuser ab einer bestimmten Größe kalkuliert und mit App-Store-Logik, in der jede Schnittstelle wieder Geld kostet. Unten stehen die günstigen Systeme, die den Preis über Funktionsgrenzen halten, an denen man nach einem Jahr steht.

Für zwei mittelgroße Häuser mit klarem Funktionsbedarf gab es dazwischen kein passendes Angebot. Drei Punkte gaben den Ausschlag gegen jede Standardlösung:

Erstens die Mandantentrennung. Zwei Betriebe unter einer Gesellschaft, mit getrennter Buchhaltung, getrennten Nummernkreisen, getrennten Portalverträgen, aber gemeinsamer Verwaltung. Die meisten Systeme lösen das über zwei Lizenzen und zwei Logins. Das verdoppelt Kosten und Pflegeaufwand für ein Problem, das sauber im Datenmodell gehört.

Zweitens die Buchungsstrecke. Ein Buchungswidget, das gestalterisch zur Webseite gehört, auf dem Handy schnell ist und die Barrierefreiheitsanforderungen nach BFSG erfüllt, ist bei Standardanbietern ein Fremdkörper im iframe. Genau dieses Widget entscheidet aber über den Provisionsanteil.

Drittens die Abgrenzung. Wer Reinigungsmanagement und Gastronomiekasse nicht braucht, soll sie nicht mitbezahlen. Weglassen ist bei zugekaufter Software keine Option.

Die Entscheidung: Bauen statt lizenzieren

Eigenentwicklung ist in der Regel der teurere Weg. Sie rechnet sich, wenn drei Bedingungen zusammenkommen: Der Funktionsumfang ist klar begrenzt, die Anforderungen sind stabil, und das Ergebnis ist über den einen Kunden hinaus verwertbar. Alle drei waren gegeben.

Vor der ersten Zeile Code stand eine Anforderungsanalyse, die den Funktionsumfang genauso präzise abgrenzt, wie sie ihn beschreibt. Ein eigenes Kapitel listet, was ausdrücklich nicht gebaut wird: kein Housekeeping, keine Tischreservierung, keine Gastronomiekasse, keine Schließsystemintegration, kein Offline-Modus. Diese Liste war das wichtigste Dokument des Projekts. Sie hat die Software schlank gehalten und damit bezahlbar.

Gearbeitet wurde in Wellen, jede mit einem eigenen Briefing und einem funktionsfähigen Zwischenstand. Jedes Modul entstand zuerst als klickbarer Prototyp, der mit dem Empfang durchgesprochen wurde, bevor implementiert wurde. Der Belegungsplan hat in dieser Schleife vier Fassungen gebraucht. Das ist billiger als eine Fassung, die im Echtbetrieb nicht funktioniert.

Die Lösung: Clavenda

Clavenda ist ein Property-Management-System für kleine und mittlere Beherbergungsbetriebe. Es deckt genau die Kette ab, die ein Haus wirtschaftlich betreibt: Anfrage, Buchung, Anreise, Aufenthalt, Rechnung, Zahlung, Buchhaltung.

Kern der Oberfläche ist der Belegungsplan. Eine Zeitachse über alle Zimmer, Buchungen als Balken, Verlängern und Verschieben per Drag-and-drop, Zimmersperren für Renovierung, die sofort auf allen Portalen greifen. Daneben das Buchungscockpit, in dem alles zu einem Aufenthalt zusammenläuft: Gastdaten, Zeitraum, Rate, Meldeschein, Folio, Zahlungen.

Am Abreisetag greift der Rechnungsteil. Posten wie Minibar oder Parkplatz laufen aufs Folio, die Rechnung entsteht in drei Schritten, der Empfänger kann Gast, Firma oder freie Adresse sein, Sammelrechnungen über mehrere Buchungen sind Standard und nicht Sonderfall. Eine ausgestellte Rechnung wird niemals geändert, sondern storniert und neu ausgestellt. Das ist keine technische Marotte, sondern die Bedingung dafür, dass der Steuerberater nicht nachfragt.

Nach außen hängt das System an einer Channel-Manager-Anbindung, die Preise und Verfügbarkeiten stündlich zu den Portalen schiebt und eingehende Buchungen automatisch importiert. Die Portalbuchung von heute Nacht steht morgens im Belegungsplan, ohne dass jemand sie abgetippt hat. Parallel läuft das eigene Buchungswidget auf der Hotelseite, mit Kreditkartenzahlung, Anzahlungslogik und Bestätigungsmail. Jede Buchung, die dort statt über ein Portal entsteht, spart 15 bis 18 Prozent.

Der technische Kern: Mandantentrennung, die nicht auf Sorgfalt beruht

Der heikelste Teil eines Multi-Mandanten-Systems ist die Frage, wie zuverlässig Daten des einen Betriebs vom anderen getrennt bleiben. Die verbreitete Antwort ist, dass die Anwendung schon die richtige Betriebs-ID mitschickt. Diese Antwort trägt genau so lange, bis irgendwo ein Filter fehlt.

Clavenda löst das eine Ebene tiefer, in der Datenbank. Jede Tabelle mit Betriebsbezug steht unter Row Level Security. Aktuell sind das 208 Regeln auf 60 Tabellen. 191 davon laufen über vier zentrale Hilfsfunktionen, die aus der angemeldeten Identität die zulässigen Betriebe ableiten. Das hat zwei Konsequenzen: Ein vergessener Filter im Anwendungscode führt nicht zu fremden Daten, sondern zu einem leeren Ergebnis. Und Änderungen am Zugriffsmodell finden an vier Stellen statt, nicht an zweihundert.

Abgesichert wird das durch Tests, die für jede Tabelle mit Betriebsbezug automatisch prüfen, dass ein Nutzer des einen Hauses null Zeilen des anderen sieht. Die Tabellenliste dafür wird zur Laufzeit aus dem Datenbankschema gelesen, nicht von Hand gepflegt. Eine neue Tabelle ist damit automatisch mitgeprüft. Ein Fehlschlag blockiert die Auslieferung.

Dazu kommt ein Zugriffsmodell für den Betreiber selbst. Support heißt bei Software mit Gästedaten fast immer, in Kundendaten zu schauen. Bei Clavenda geht das nur über eine ausdrücklich eröffnete Sitzung: ein Betrieb, ein angegebener Grund, acht Stunden Laufzeit, jede Aktion im Protokoll. Außerhalb einer solchen Sitzung sieht auch der Betreiber null Zeilen.

Compliance ist kein Anhang, sondern Architektur

Ein Beherbergungsbetrieb arbeitet in einem dicht regulierten Feld. Diese Anforderungen sind nicht nachträglich einbaubar, sie bestimmen das Datenmodell.

Rechnungen folgen einem Nummernkreis je Betrieb, lückenlos und unveränderlich, mit Storno statt Korrektur. Das ist die GoBD-Anforderung, an der ältere Systeme regelmäßig scheitern.

Der Steuerberater bekommt einen Monatsexport aus Buchungssätzen und Belegen. Bewusst als Datei statt über eine kostenpflichtige Schnittstelle, weil das Ergebnis identisch und der laufende Aufwand null ist.

Datenschutz ist als Funktion umgesetzt, nicht als Versprechen. Gastprofile lassen sich anonymisieren, ohne dass buchhalterisch relevante Zahlen verschwinden. Ein nächtlicher Lauf löscht oder pseudonymisiert Daten nach Aufbewahrungsklasse, Meldescheine getrennt von Rechnungsdaten.

Der Meldeschein wird nur noch dort erhoben, wo er seit Januar 2025 noch Pflicht ist, also für Gäste ohne deutsche Staatsangehörigkeit. Eine Kleinigkeit, die im Alltag am Empfang jeden Tag Zeit spart.

Barrierefreiheit nach WCAG 2.2 AA gilt für die gesamte Oberfläche und ist für das Buchungswidget durch das Barrierefreiheitsstärkungsgesetz ohnehin verpflichtend.

Was wir bewusst nicht gebaut haben

Clavenda kann kein Reinigungsmanagement, keine Tischreservierung und keine Kassenfunktion für den Barbetrieb. Das ist keine Lücke, sondern eine Entscheidung.

Die Kassenfunktion ist das beste Beispiel. Sobald ein System Bargeschäfte aufzeichnet, greifen Paragraf 146a AO und die Kassensicherungsverordnung, mit TSE-Pflicht, Belegausgabepflicht und einem eigenen Exportformat für die Betriebsprüfung. Das ist ein eigenes Produkt, kein Feature. Wer es braucht, ist mit einer spezialisierten Kasse besser bedient. Wer es nicht braucht, soll es nicht mitfinanzieren.

Dieselbe Logik hat eine geprüfte Schließsystemanbindung aus dem Projekt gehalten: Das System hätte einen lokalen Windows-Dienst im Hotel vorausgesetzt und damit die reine Cloud-Architektur aufgebrochen. Die Anbindung wurde nach der Analyse abgesagt, nicht halb gebaut.

Technologie-Stack

Clavenda läuft vollständig serverlos. Frontend und Anwendungslogik in Next.js auf Vercel, Datenhaltung und Authentifizierung in einer PostgreSQL-Datenbank bei Supabase mit Row Level Security als Zugriffsschicht. Zahlungen laufen über Stripe, je Betrieb mit eigenem Konto, inklusive Kartenhinterlegung, Vorautorisierung und Rückerstattung. Die Portalanbindung läuft über Channex.io, der transaktionale Mailversand über SendGrid mit eigener Absenderdomain je Haus, das Fehler-Monitoring über Sentry.

Der aktuelle Stand: rund 30 Module auf 61 Seiten, 112 serverseitige Aktionen, 33 Datenbankfunktionen, 111 Migrationen. Die laufenden Infrastrukturkosten für beide Häuser zusammen liegen bei unter 200 Euro im Monat. Das ist der eigentliche Grund, warum das Preismodell funktioniert.

Das Ergebnis

Der Umstieg lief an einem Tag. Stammdaten und Zukunftsbuchungen wurden ab Stichtag übernommen, die historischen Buchungen bleiben lesend im Altsystem, Schulung von Empfang und Sekretariat an zwei Nachmittagen, Umschaltung der Portale zum 1. September 2026. Kein Parallelbetrieb, weil doppelte Datenpflege jede Einführung ruiniert.

Was sich im Alltag geändert hat:

• Portalbuchungen werden nicht mehr abgetippt, sondern stehen morgens im Plan.
• Zwei Betriebe laufen in einer Oberfläche mit einem Login, bei vollständig getrennter Buchhaltung.
• Die Rechnungsstellung am Abreisetag ist ein Vorgang statt drei Programmwechsel.
• Der Monatsabschluss für den Steuerberater ist ein Export statt einer Sammelaktion.
• Die eigene Buchungsstrecke ist gestalterisch Teil der Hotelseite und nicht mehr der schlechtere Weg gegenüber dem Portal.

Vom Kundenprojekt zum Produkt

Der interessanteste Teil dieser Case Study ist nicht die Software, sondern was danach passiert ist. Ein System, das für zwei Häuser gebaut wurde, ist mandantenfähig. Ein System, das mandantenfähig ist, ist ein Produkt.

Clavenda wird seit dem Go-Live als eigenständiges Angebot geführt, mit einem Preismodell aus fünf unabhängigen Bausteinen: Lizenz je Betrieb nach Zimmerzahl gestaffelt, Portalanbindung nach Anzahl der Kanäle, Kartenterminal optional, Onboarding einmalig nach Aufwand, Support in drei Stufen. Alle Preise stehen öffentlich auf der Produktseite. Ein Haus mit 42 Zimmern und zwei Portalen liegt bei etwas über 400 Euro im Monat.

Das ist derselbe Hebel, den wir auch bei CeleroPress und den Smart Assets anwenden: Wir lizenzieren keine fremde Software, wir besitzen den Code. Jedes Projekt macht das Produkt besser, und der nächste Kunde bekommt das Ergebnis, ohne die Entwicklung noch einmal zu bezahlen.

Fazit

Der Standardweg wäre gewesen, drei Anbieter zu vergleichen, den mittleren zu nehmen und mit den Kompromissen zu leben. Er wäre auf zwei Jahre gerechnet nicht billiger gewesen und hätte die eigentlichen Probleme, Provisionsabhängigkeit und getrennte Buchhaltung, nicht gelöst.

Software selbst zu bauen ist nicht immer die richtige Antwort. Sie ist es dann, wenn der Bedarf klar begrenzt ist, die Anforderungen stabil sind und das Ergebnis mehr als einem Kunden nutzt. In diesem Projekt war das der Fall. Aus einer Ablösung ist ein Produkt geworden, und aus einem Kunden der erste Referenzbetrieb.