LUMA ist als Plattform gedacht, auf der mehrere Kunden produktiv arbeiten koennen, ohne sich Infrastruktur, Datenbestand oder operative Zustaende unsauber zu teilen. Im Mittelpunkt steht nicht nur ein ansprechendes Frontend, sondern eine Architektur, die Mandanten sauber trennt, Provisionierung kontrolliert, Abrechnung integriert und spaetere Erweiterungen nicht blockiert. Das Projekt adressiert damit ein Problem, das viele SaaS-Produkte zu spaet loesen: eine belastbare Struktur von Anfang an.
Gerade bei neuen SaaS-Produkten wird am Anfang oft nur auf Geschwindigkeit optimiert. Eine Anwendung, eine Datenbank, ein gemeinsamer Zustand fuer alle Kunden, technisch zunaechst bequem, langfristig aber problematisch. Sobald unterschiedliche Tarife, Rollenmodelle, Kundengrenzen, Abrechnungslogik und individuelle Konfigurationen hinzukommen, wird aus einer schnellen Loesung ein strukturelles Risiko.
Das betrifft nicht nur Sicherheit und Datenschutz. Es betrifft auch Wartbarkeit, Produktlogik und Betrieb. Wenn Mandanten nicht sauber getrennt sind, lassen sich Zustaendigkeiten, Limits, Berechtigungen und Billing spaeter nur mit hohem Aufwand nachruesten. Gleichzeitig steigt das Risiko, dass Daten unsauber vermischt werden oder Produktentscheidungen durch technische Altlasten blockiert werden.
Das eigentliche Problem ist also nicht, ob ein SaaS-Produkt funktioniert. Die entscheidende Frage ist, ob es sauber wachsen kann. Wer mehrere Kunden bedienen will, braucht eine Architektur, die Mandanten, Abrechnung, Provisionierung und Administration von Beginn an systematisch trennt.
Die Plattform verwaltet Kunden, Pakete, Provisionierung und Berechtigungen zentral, waehrend jeder Tenant in einem sauber abgegrenzten Systemkontext arbeitet. So bleiben Daten, Rollen und Produktzustaende kontrollierbar, auch wenn das System waechst.
LUMA ist nicht als einzelnes SaaS-Produkt gedacht, sondern als technische und operative Grundlage fuer produktive Mandantensysteme. Im Zentrum steht eine Plattform, die Kunden onboardingfaehig macht, Pakete sauber verwaltet, Rollen und Zugriffe kontrolliert und wiederkehrende Betriebsprozesse zentral steuert. Wichtig ist dabei, dass Administration und Mandantenbetrieb nicht vermischt werden.
Die Plattform setzt deshalb auf eine klare Trennung zwischen zentraler Steuerung und tenant-spezifischer Nutzung. Provisionierung, Abrechnung, Paketlogik und administrative Eingriffe werden im Plattform-Layer verwaltet. Der eigentliche Arbeitskontext der Kunden bleibt davon getrennt. Dadurch entsteht eine Architektur, die sowohl sicherer als auch langfristig wartbarer ist.
Gleichzeitig wird der Techstack bewusst reduziert. Alles, was Kernlogik betrifft, bleibt im primaeren Backend und in sauber definierten Services. Externe Workflow-Tools oder lokale KI-Komponenten werden nur dort eingesetzt, wo sie dem Produkt wirklich helfen, nicht als dekorative Zusatztechnologien. Das Ergebnis ist eine Plattform mit technischer Klarheit statt Stack-Ueberfrachtung.
Zentrale Steuerung fuer Kunden, Pakete und Systemzustaende
Der Admin-Layer bildet die operative Schaltzentrale der Plattform. Hier werden Kunden angelegt, Pakete verwaltet, Limits definiert und Provisionierungsprozesse gestartet. Wichtig ist, dass diese Logik nicht in beliebigen Einzelmasken verteilt wird, sondern als klarer Plattformbereich verstanden wird. So bleibt nachvollziehbar, wer welche systemweiten Eingriffe vornehmen darf.
Mandanten sauber abgegrenzt statt nur logisch markiert
Mandanten sollen nicht nur per Datenbankspalte unterschieden werden, sondern in ihrer Produktlogik und ihrem Zugriffskontext klar getrennt bleiben. Je nach Produkt kann das ueber eigene Datenbanken, eigene Schemas oder klar isolierte Scopes erfolgen. Entscheidend ist, dass Trennung architektonisch abgesichert ist und nicht nur ueber gute Absichten im Code laeuft.
Neue Kunden werden systematisch eingerichtet, nicht manuell zusammengebaut
Onboarding und Einrichtung eines neuen Tenants muessen reproduzierbar sein. Dazu gehoeren Datenbank-Setup, Rollenmodelle, Paketparameter, Zugriffsrechte und erste Systemzustaende. Provisionierung ist damit kein operativer Sonderfall mehr, sondern Teil der Plattformlogik. Das reduziert Fehler und macht Wachstum ueberhaupt erst handhabbar.
Abrechnung ist Teil der Produktlogik, nicht nachgelagerte Verwaltung
Pakete, Limits, Upgrades und Statusaenderungen greifen direkt in die Plattform ein. Billing darf deshalb nicht losgeloest vom eigentlichen Produktbetrieb behandelt werden. Ueber eine saubere Integration, etwa mit Stripe und Webhooks, lassen sich Tarifzustaende, Freigaben und Nutzungsgrenzen kontrolliert mit dem Mandantenstatus verknuepfen.
Klare Oberflaeche fuer produktive Nutzung statt nur schoener Screens
Das Frontend soll nicht nur modern wirken, sondern echte Nutzungssicherheit bieten. Dazu gehoert ein konsistentes Komponentenmodell, saubere API-Anbindung und eine Oberflaeche, die Rollen, Paketgrenzen und Zustaende verstaendlich macht. Gerade im SaaS-Kontext entscheidet nicht nur die Backend-Architektur, sondern auch die UI darueber, ob ein System im Alltag tragfaehig ist.
Neue Module duerfen die Kernarchitektur nicht beschaedigen
Eine gute Plattform erkennt man daran, dass sie neue Funktionen aufnehmen kann, ohne ihre Grundstruktur zu verlieren. LUMA ist deshalb so gedacht, dass spaetere Features, Automationen, Reports, KI-Module oder Drittintegrationen auf eine bestehende Plattformlogik aufsetzen, statt neue Sonderwege zu eroeffnen. Das schuetzt vor spaetem Architekturbruch.