Buchungsplattform für Camping, Stellplätze, Marinas und Parkplätze: 31 Standorte in 15 Wochen
EPSIA entwickelte für die Modusan GmbH aus Berlin eine Buchungs- und Betriebsplattform für unterschiedliche Arten buchbarer Plätze – vom Wohnmobilstellplatz und Campingplatz über Zeltflächen bis zu Marina-Liegeplätzen und Parkplätzen.
Gäste buchen und bezahlen über einen QR-Code mit dem eigenen Smartphone. Betreiber verwalten Einheiten, Leistungen, Preise und Verfügbarkeiten selbst. Jeder Standort läuft dabei in einer technisch getrennten Instanz mit eigener Datenbank, verwendet aber denselben Softwarestand.
Von der ersten Kundeninstanz bis zum 31. Standort vergingen 15 Wochen. Heute bietet Modusan die Plattform eigenen Kunden als Dienst an.
- 31Standorte bei 20 Betreibern mit getrennten Instanzen
- 15Wochen von der ersten Kundeninstanz bis zum 31. Standort
- 99.255Zeilen eigener Code in sechs Repositories
- 874automatisierte Tests plus Browsertests vor dem Rollout
Die Fallstudie zeigt den Projektverlauf in sieben Schritten: Auftrag, Architektur, Gastbuchung, Betreiberportal, Leistungskatalog, Betrieb und Ergebnis.
1 Auftrag: Eine Plattform für unterschiedliche Arten buchbarer Plätze
Modusan benötigte eine Plattform, die nicht auf einen einzelnen Betreiber oder einen bestimmten Platztyp zugeschnitten ist.
Wohnmobilstellplätze, Campingplätze, Zeltflächen, Marina-Liegeplätze oder Parkplätze unterscheiden sich in ihren Einheiten und Leistungen, benötigen aber ähnliche Grundfunktionen: Verfügbarkeit prüfen, buchen, bezahlen, verlängern und verwalten.
Gleichzeitig sollte jeder Betreiber seine Angebote und Preise selbst pflegen können. Die Daten und der Betrieb einzelner Standorte sollten technisch voneinander getrennt bleiben.
EPSIA übernahm Architektur, Entwicklung und technischen Betrieb der Plattform. Die Entwicklung begann im November 2025 und erfolgt im Rahmen eines laufenden Entwicklungsvertrags.
2 Architektur: Gemeinsame Anwendungen, getrennte Instanzen
Die Plattform trennt gemeinsam genutzte Anwendungen von den Daten und Diensten der einzelnen Standorte.
Zentral betrieben werden das Buchungsfrontend für Gäste, das Portal für Betreiber sowie die Anwendung für Deployment und Betrieb. Jeder Standort erhält dagegen eine eigene Instanz für seine operativen Daten und Prozesse.
Die Architektur besteht aus:
- Buchungsfrontend
- Next.js-Anwendung für Gäste, mehrsprachig und für alle angeschlossenen Standorte nutzbar.
- Betreiberportal
- Zentrale Oberfläche für Betreiber und Benutzer sowie Zugang zum Administrationsbereich der jeweiligen Standorte.
- Standortinstanz
- Express-API mit eigener MariaDB-Datenbank für Einheiten, Leistungen, Buchungen, Käufe und angebundene Geräte.
- Deployment
- Containerisierte Dienste für amd64 und arm64; Instanzen können auf einem Raspberry Pi am Standort oder auf zentraler Serverinfrastruktur betrieben werden.
- TLS und Routing
- Caddy stellt die benötigten verschlüsselten Dienste bereit.
- Internes Netz
- Die Systemkomponenten kommunizieren über ein gesichertes WireGuard-Netz miteinander.
- Zahlung
- PayPal ist als Zahlungsdienst integriert. Zugangsdaten für Zahlungsanbieter werden verschlüsselt in der jeweiligen Instanz gespeichert.
Die Trennung der Instanzen begrenzt gleichzeitig die Auswirkungen technischer Störungen: Ist eine Standortinstanz nicht erreichbar, bleiben die übrigen Standorte davon unabhängig.
3 Gastbuchung: Vom QR-Code bis zum Zugangscode
Am Standort führt ein QR-Code direkt zum passenden Angebot. Der Gast sieht dort die verfügbaren Buchungsarten, Preise, Bilder und Verfügbarkeiten.
Je nach Standort kann es sich beispielsweise um Kurzzeitparken, eine Übernachtung auf einem Stellplatz oder die Buchung einer bestimmten Einheit handeln.
Der Buchungsprozess umfasst:
- Auswählen
- Der Gast wählt Zeitraum oder Aufenthaltsdauer, Einheitentyp und verfügbare Zusatzleistungen. Erforderliche Angaben wie das Kennzeichen werden während des Buchungsprozesses erfasst und validiert.
- Prüfen
- Die Plattform ermittelt Verfügbarkeit und Gesamtpreis anhand der Regeln und Leistungen des jeweiligen Standorts.
- Bezahlen
- Nach den erforderlichen Zustimmungen wird die Zahlung über den angebundenen Zahlungsdienst durchgeführt.
- Bestätigen
- Nach erfolgreicher Zahlung bestätigt die Standortinstanz die Buchung, verbucht den Kauf und erzeugt einen vierstelligen Zugangscode.
- Beleg
- Die Buchungsdaten können als PDF ausgegeben und optional per E-Mail versendet werden.
- Verlängern
- Über Zugangscode und Kennzeichen kann der Gast einen bestehenden Aufenthalt aufrufen und – sofern verfügbar – weitere Nächte oder Leistungen buchen. Der vorhandene Zugangscode bleibt bestehen.
Lebenszyklus einer Buchung
Die Plattform bildet den gesamten Lebenszyklus einer Buchung über definierte Zustände ab: vorläufig, reserviert, bestätigt, aktiv und geschlossen.
Zeitgesteuerte Prozesse halten diese Zustände automatisch aktuell:
- Nicht bezahlte vorläufige Buchungen werden nach einer konfigurierbaren Frist geschlossen.
- Bestätigte Buchungen werden zum Beginn des Aufenthalts aktiviert.
- Buchungen, deren Beginn ohne erfolgreiche Bestätigung verstrichen ist, werden geschlossen.
- Nach dem Ende des Aufenthalts wird die Buchung automatisch beendet.
- Belegungsprüfungen verhindern überschneidende Buchungen derselben Einheit.
- Transaktionen werden so verarbeitet, dass derselbe Kauf nicht mehrfach verbucht wird.
4 Betreiberportal: Buchungen, Belegung und Betrieb verwalten
Jeder Standort verfügt über einen Administrationsbereich im Betreiberportal.
Mitarbeiter können dort beispielsweise Buchungen für Gäste vor Ort anlegen, über Kennzeichen oder Zugangscode nach bestehenden Aufenthalten suchen, Buchungen verlängern sowie An- und Abreisen einsehen.
Zum Funktionsumfang gehören außerdem:
- Belegungskalender
- Verfügbarkeiten und Sperrzeiten
- Übersicht aktueller An- und Abreisen
- Stammdaten und Einheitentypen
- Leistungen und Preise
- Konfiguration der Zahlungsanbieter einschließlich Verbindungstest
- Geräteverwaltung
- Backups
- Umsatz- und Transaktionsauswertungen
- Auslastung nach Einheitentyp
Die Auswertung stellt unter anderem Monatsumsatz und Steueranteile, Tagesumsätze nach Leistungen sowie die Auslastung unterschiedlicher Einheitentypen dar.
5 Leistungskatalog: Der Betreiber definiert sein Geschäftsmodell
Ein wesentlicher Teil der Plattform ist nicht fest auf Camping oder Wohnmobilstellplätze programmiert.
Betreiber können eigene Einheitentypen anlegen – beispielsweise Standardstellplatz, XXL-Stellplatz, Zeltfläche, Liegeplatz oder PKW-Stellplatz. Ebenso lassen sich eigene Leistungen mit Preis, Steuersatz, Mengengrenzen und zeitlichen Regeln definieren.
Dazu können beispielsweise gehören:
- Übernachtungen
- Kurzzeitparken
- Strom
- Duschen
- Spät-Check-out
- Internetzugang
- personenabhängige Abgaben
- automatisch zugeordnete Leistungen
Die Preisberechnung erfolgt über definierte Abrechnungsarten. Dazu gehören unter anderem:
- pro Nacht
- Preis × Anzahl der Nächte
- pro Stunde
- Preis × Stunden, optional innerhalb eines zulässigen Zeitfensters
- pauschal
- einmaliger Betrag
- nach Menge
- Preis × Anzahl oder Verbrauchsmenge
- Tagessatz
- Preis × Aufenthaltstage
- Tagessatz × Menge
- beispielsweise Aufenthaltstage × Personen × Preis
- automatisch
- Leistung wird einer Buchung ohne separate Auswahl zugeordnet
Ein Betreiber kombiniert daraus die für seinen Standort benötigten Einheiten, Leistungen und Regeln.
Dadurch wird ein neuer Standort in vielen Fällen konfiguriert und ausgerollt, statt dafür eine eigene Softwareversion entwickeln zu müssen.
6 Betrieb: Einen Softwarestand auf viele Instanzen ausrollen
EPSIA betreibt für die Plattform einen zentralen Build- und Deployment-Prozess.
Ein gemeinsamer Versionsstand umfasst API, Buchungsfrontend, Betreiberportal und weitere Dienste. Die benötigten Images werden für amd64 und arm64 erzeugt und in einer eigenen Registry bereitgestellt.
Die Deployment-Anwendung rollt eine neue Version anschließend kontrolliert aus: zunächst zentrale Dienste und danach die einzelnen Standortinstanzen.
Für eine Standortinstanz umfasst der Prozess unter anderem:
- Datensicherung
- Bereitstellung der neuen Version
- Neustart der Dienste
- Health-Check
- Prüfung des Datenbankschemas
Neue Standorte werden über denselben Prozess eingerichtet.
Automatische Prüfung vor dem Rollout
Vor der Auslieferung durchläuft die Plattform automatisierte Prüfungen:
- 874 automatisierte Tests in den Repositories
- Browsertests für zentrale Benutzerabläufe
- ein Release-Test der vollständigen Buchungsstrecke
- Health-Checks nach dem Deployment
Im laufenden Betrieb kontrolliert ein Monitor die Instanzen regelmäßig und erstellt eine tägliche Zusammenfassung. Störungen können über das integrierte Ticketsystem weiterverarbeitet werden.
Für Last- und Funktionstests existiert zusätzlich ein Simulator, der mit bis zu 50 simulierten Teilnehmern Buchungsverkehr gegen die API erzeugt.
EPSIA setzt bei der Entwicklung auch KI-Werkzeuge ein. Änderungen müssen unabhängig davon dieselben Architekturregeln, automatisierten Tests und Release-Prüfungen durchlaufen, bevor sie ausgerollt werden.
Umfang der Plattform
- Eigener Code
- 99.255 Zeilen in sechs Repositories — Deploy-Anwendung 38.834, Buchungsfrontend 17.514, Betreiberportal 17.108, API 15.944, Geräte-Hub 7.529, Simulator 2.326
- Tests
- 874 automatisierte Tests in 104 Testdateien plus Browsertests
- Änderungen
- 742 Commits zwischen November 2025 und September 2026
7 Ergebnis: Von der ersten Kundeninstanz zu 31 Standorten in 15 Wochen
Die erste Kundeninstanz der Plattform ging am 12. Mai 2026 in Betrieb. Am 27. August 2026 wurde der 31. Standort eingerichtet – ein Zeitraum von 15 Wochen.
- 31 Standorte bei 20 Betreibern verwenden dieselbe Softwarebasis.
- Jeder Standort besitzt eine technisch getrennte Instanz mit eigener Datenbank.
- Neue Standorte können über Konfiguration und den bestehenden Deployment-Prozess eingerichtet werden.
- Gäste können selbst buchen, bezahlen und bestehende Aufenthalte verlängern.
- Betreiber verwalten Einheiten, Leistungen, Preise und Verfügbarkeiten ohne Softwareänderung.
- Modusan bietet die Plattform als Dienst für eigene Kunden an.
Die Plattform wird gleichzeitig weiterentwickelt. Ein Geräte-Hub für die direkte Verbindung mit lokaler Versorgungstechnik wird bereits gegen eine Modbus-Simulation getestet. Er ist derzeit noch nicht Bestandteil der produktiven Kundenstandorte.
Wofür steht dieses Projekt?
Das Projekt zeigt, wie EPSIA aus einem spezialisierten Geschäftsprozess eine wiederverwendbare Softwareplattform entwickelt.
Einheiten, Leistungen, Preise und betriebliche Regeln sind konfigurierbar, während alle Standorte auf derselben Softwarebasis bleiben. Technisch getrennte Instanzen isolieren Betreiber und Standorte voneinander; ein gemeinsamer Build-, Test- und Deployment-Prozess ermöglicht trotzdem die zentrale Weiterentwicklung.
Die Plattform verbindet damit Fachanwendung, Mehrstandortbetrieb und automatisierten Softwarebetrieb in einem System.
Wie beginnt ein Projekt für eine Fachanwendung mit EPSIA?
Ein Projekt für eine Fachanwendung kann bei EPSIA mit einer Anforderungsanalyse zu einem vereinbarten Festpreis beginnen.
EPSIA analysiert dabei Geschäftsabläufe, Daten, Benutzerrollen, Schnittstellen und Anforderungen an den späteren Betrieb. Das Ergebnis wird in einem Pflichtenheft so beschrieben, dass Umfang und technische Struktur der anschließenden Entwicklung belastbar festgelegt werden können.
Auf dieser Grundlage kann EPSIA die Umsetzung als Festpreisprojekt anbieten.
Mehr zur Leistung unter Fachanwendungen für spezialisierte Geschäftsprozesse.
Eckdaten
- Kunde
- Modusan GmbH, Berlin
- Leistung
- Fachanwendungen
- Anwendung
- Buchungs- und Betriebsplattform für Camping, Stellplätze, Marinas und Parkflächen
- Zeitraum
- seit November 2025, laufend
- Technik
- TypeScript, Node.js, Express, Next.js, React, Prisma, MariaDB, Docker für amd64/arm64, Caddy, WireGuard, PayPal, Playwright, Jest, C++/Qt.