Der Kernstack
Frontend: WeWeb, pixelgenaue UI, verbindet sich mit beliebigen Backends, wird auf deiner eigenen Domain über Cloudflare CDN deployed.
Datenbank + Auth: Supabase, PostgreSQL, Row Level Security, Echtzeit-Subscriptions, Dateispeicher.
Geschäftslogik + API: Xano, REST-API-Builder, benutzerdefinierte Geschäftslogik, Drittanbieter-Integrationen, Webhooks.
Zahlungen: Stripe, Abonnements, Rechnungen, Webhooks zurück zu Xano.
E-Mail: Brevo oder SendGrid, transaktionale E-Mails, ausgelöst von Xano.
Dieser Stack verarbeitet 10.000 MAU ohne zu schwitzen. Wir haben ihn mit 50.000 MAU ohne Infrastrukturänderungen betrieben. Für deutsche SaaS-Unternehmen, die Mittelstandskunden in der DACH-Region ansprechen, ist das eine bewährte und getestete Grundlage.
Multi-Tenancy mit Supabase RLS
Jede Tabelle hat eine workspace_id-Spalte. Alle Row Level Security-Policies filtern auf workspace_id = auth.jwt() ->> 'workspace_id'.
Nutzer gehören zu Workspaces über eine workspace_members-Tabelle mit einer Rollenspalte (owner, admin, member). Wenn ein Nutzer sich einloggt, enthält das JWT ihre workspace_id und Rolle, Supabase erzwingt das automatisch auf Datenbankebene.
Das ist die wichtigste Architekturentscheidung in einer B2B-SaaS. Mache es von Anfang an richtig. Wir haben Unternehmen gesehen, die das in der Validierungsphase übersprungen haben und dann eine vollständige Datenbankmigration benötigten, als sie ihre ersten Unternehmenskunden bekamen, ein kostspieliger Prozess.
Abrechnungsarchitektur mit Stripe
In Xano erstellst du einen Webhook-Endpoint, der Stripe-Events empfängt. Verarbeite: checkout.session.completed (Abonnement-Eintrag erstellen), customer.subscription.updated (Plan aktualisieren), invoice.payment_failed (Zugriff einschränken).
Speichere den Abonnementstatus in einer workspace_settings-Tabelle. In WeWeb prüfst du den Abonnementstatus vor dem Rendern von Premium-Features, und in Supabase RLS-Policies für Datenbankeinschränkungen.
Vertraue niemals dem Frontend für Abrechnungsgates. Überprüfe immer in der Datenbank. Für deutsche Kunden, die in EUR abgerechnet werden: Stripe unterstützt EUR-Preisgestaltung und automatisches MwSt-Handling für die deutsche Mehrwertsteuer (19 % Standard, 7 % ermäßigt), was die Buchführung erheblich vereinfacht.
Performance-Optimierung
Indexstrategie: Indiziere jeden Fremdschlüssel, jede Status/Typ-Spalte, die in Filtern verwendet wird, und jede Spalte, nach der du sortierst. In Supabase dauert das 2 Minuten im SQL-Editor.
Paginierung: Alle List-Endpoints müssen paginieren. Gib niemals unbegrenzte Queries zurück. Verwende cursorbasierte Paginierung für Echtzeit-Daten (unendliches Scrollen) und Offset für Admin-Tabellen.
Caching: Xano unterstützt Antwort-Caching für Endpoints, die dieselben Daten für alle Nutzer zurückgeben (öffentlicher Inhalt, Lookup-Tabellen). Verwende es aggressiv. Ein gut gecachter Xano-Endpoint kann Tausende von Aufrufen pro Sekunde verarbeiten ohne Supabase zu belasten.
Monitoring und Fehlerbehandlung
Füge Sentry zu deinem WeWeb Custom Code für Frontend-Fehler hinzu. Xano loggt alle API-Anfragen, exportiere sie zu Datadog oder verwende Xanos eingebautes Fehler-Monitoring.
Für kritische Hintergrundaufgaben (Abrechnungs-Webhooks, E-Mail-Trigger) füge Fehlerbenachrichtigungen zu Slack über Make oder n8n hinzu. Du solltest von Fehlern wissen, bevor es deine Nutzer tun.
Datenbanküberwachung: Supabase liefert Query-Performance-Einblicke. Überprüfe langsame Queries wöchentlich. Eine häufige Ursache für Performance-Abbau in wachsenden Unternehmen sind Queries, die bei 100 Zeilen gut funktionieren, aber bei 100.000 katastrophal langsam sind, frühzeitige Indizierung beseitigt dieses Problem.
Multi-Tenancy-Muster: Gemeinsame vs. isolierte Datenbanken
Es gibt drei Multi-Tenancy-Modelle: eine gemeinsame Datenbank mit RLS (alle Mandanten in denselben Tabellen, isoliert durch Policies), eine gemeinsame Datenbank mit separaten Schemas (jeder Mandant hat sein eigenes PostgreSQL-Schema) und separate Datenbanken pro Mandant. Die überwiegende Mehrheit der SaaS-Apps mit 10.000 Nutzern oder weniger sollte das erste Modell verwenden, eine gemeinsame Datenbank mit RLS. Es ist am einfachsten zu bauen, am günstigsten zu betreiben, und Supabases RLS macht es wirklich sicher.
Separate Schemas pro Mandant (oft "Schema-per-Tenant" genannt) werden relevant, wenn Mandanten wirklich unterschiedliche Datenstrukturen haben, in der Praxis selten. Separate Datenbanken pro Mandant sind ein Enterprise-Feature, das verwendet wird, wenn Mandanten vertragliche Garantien zur Datenresidenz oder eigene Datenbank-Credentials benötigen. Bei App Studio implementieren wir das Modell einer gemeinsamen Datenbank mit RLS für alle SaaS-Produkte, bis ein Kunde eine spezifische vertragliche Anforderung für stärkere Isolierung hat.
Das entscheidende Implementierungsdetail: Jeder INSERT muss workspace_id explizit setzen, und deine RLS-WITH-CHECK-Policies müssen erzwingen, dass workspace_id mit dem Workspace des authentifizierten Nutzers übereinstimmt. Wenn du das auch nur bei einem einzigen Endpoint übersiehst, könnte ein Nutzer Daten in den Workspace eines anderen Mandanten einfügen. Wir validieren das mit einer Sicherheits-Testsuite, die zwei Test-Workspaces erstellt und die Datenisolierung über alle 50+ Endpoints hinweg überprüft.
Datenbankdesign-Prinzipien für No-Code-SaaS
Das Datenbankschema ist das Fundament, auf dem alles andere ruht. Schlechte Schema-Entscheidungen in Monat 1 verursachen kaskadierende Schmerzen in Monat 12. Das wichtigste Prinzip: Gestalte für deine Queries, nicht für theoretische Normalisierung. Wenn du Projekte immer zusammen mit ihrem zugehörigen Workspace und Owner abfragst, speichere workspace_id und owner_id direkt in der projects-Tabelle, statt jedes Mal über workspace_members zu joinen.
Verwende Datenbank-Constraints als zweite Validierungsebene. Fremdschlüssel (project.workspace_id verweist auf workspaces.id), Not-Null-Constraints für Pflichtfelder und Check-Constraints für enum-artige Werte (status IN ('active', 'paused', 'cancelled')). Diese Constraints fangen Bugs in deiner Anwendungsschicht ab, bevor sie deine Daten beschädigen. Supabase erzwingt diese nativ, füge sie hinzu, wenn du deine Tabellen erstellst, nicht als nachträglichen Gedanken.
Verwende für SaaS-Abrechnung eine dedizierte subscription-Tabelle, statt Plan-Daten direkt in der workspace-Tabelle zu speichern. Ein Abonnement hat einen Lebenszyklus (trialing, active, past_due, cancelled) mit Zeitstempeln für jeden Statusübergang. Dies als separate Entität zu speichern macht die Abrechnungslogik sauber und gibt dir einen vollständigen Audit-Trail, unverzichtbar zur Klärung von Abrechnungsstreitigkeiten und zur Fehlersuche bei Umsatzanomalien.
Caching-Strategie: Was wird wo gecacht
Caching in einem No-Code-SaaS-Stack funktioniert auf drei Ebenen: Xano-Endpoint-Caching (Antwortebene), Supabase Materialized Views (Query-Ebene) und WeWeb Client-seitiger State (UI-Ebene). Jede erfüllt einen anderen Zweck und hat unterschiedliche Invalidierungsanforderungen.
Xano-Endpoint-Caching eignet sich für Daten, die für alle Nutzer gleich sind und sich selten ändern: Lookup-Tabellen (Länderlisten, Branchenkategorien), öffentliche Preispläne, Feature-Flag-Konfigurationen. Setze eine TTL von 5 bis 60 Minuten, je nachdem, wie oft sich die Daten ändern. Das reduziert die Datenbanklast für Endpoints, die bei jedem Seitenaufruf abgerufen werden, erheblich.
Supabase Materialized Views sind das richtige Werkzeug für teure Aggregations-Queries: Nutzungsmetriken auf Workspace-Ebene, monatliche Reportdaten, Leaderboard-Berechnungen. Aktualisiere sie nach einem Zeitplan (alle 15 Minuten für nahezu Echtzeit-Dashboards, einmal täglich für Abrechnungsberichte) mit Supabases Cron-Erweiterung. Wir haben die Ladezeit von Dashboards bei analytiklastigen SaaS-Apps durch die Verlagerung von Aggregationen auf Materialized Views um das 10-fache reduziert.
WeWeb-Client-seitiges Caching über seinen eingebauten Variablenspeicher reduziert redundante API-Aufrufe innerhalb einer Session. Cache die Workspace-Einstellungen, den Abonnementstatus und die Feature-Flags des aktuellen Nutzers beim Login, diese werden auf jeder Seite benötigt und ändern sich nicht innerhalb der Session. Invalidiere den Cache beim Logout und bei Plan-Upgrades.
Hintergrundjobs: Muster für asynchrone Verarbeitung
Jede Operation, die länger als 500ms dauert, sollte asynchron sein. In einem No-Code-SaaS-Stack laufen Hintergrundjobs in Xanos Task-Queue, ausgelöst über Make.com- oder n8n-Scheduler, oder über Supabase Edge Functions, die durch Datenbankänderungen ausgelöst werden.
Die häufigsten Hintergrundjobs in den SaaS-Produkten, die wir bauen: Verarbeitung von Abonnement-Verlängerungen (alle Workspaces mit heute fälligen Verlängerungen prüfen, Stripe belasten, Abonnementstatus aktualisieren, Quittungs-E-Mail senden), Generierung von Datenexporten (Nutzer fordert einen CSV-Export an, ein Job generiert ihn und mailt einen Download-Link, blockiere dafür niemals die UI), Drittanbieter-Synchronisation (neue CRM-Kontakte zu HubSpot pushen, Kalenderereignisse mit Google Calendar synchronisieren) und Nutzungsmessung (API-Aufrufe oder Feature-Nutzung stündlich für die Abrechnung aggregieren).
Fehlerbehandlung für Hintergrundjobs erfordert mehr Sorgfalt als synchrone Endpoints, es wartet kein Nutzer auf eine Antwort. Jeder Job sollte: seinen Start und sein Ende loggen, alle Fehler abfangen und in eine job_errors-Tabelle schreiben, bei Fehlern einen Slack-Alert senden und exponentielle Backoff-Retry-Logik für vorübergehende Fehler implementieren (Netzwerkfehler, Rate Limits). Xanos Task-Queue handhabt Retries nativ; implementiere für Make.com-ausgelöste Jobs die Retry-Logik im Szenario.
Eine No-Code-SaaS in Produktion überwachen
Produktionsüberwachung ohne DevOps-Team erfordert die Wahl der richtigen Tools und automatisierte Alerts. Für den Stack, den wir verwenden, besteht das minimal tragfähige Monitoring-Setup aus: Sentry für Frontend-Fehler (WeWeb-Custom-Code-Integration), Xanos eingebauten Request-Logs mit Fehler-Alerting, Supabases Datenbank-Performance-Einblicken und Connection-Pool-Monitoring sowie Stripes Dashboard für Zahlungsfehlerraten.
Verfolge über das Fehler-Monitoring hinaus geschäftliche Health-Metriken: tägliche aktive Nutzer (Abfrage in Supabase), Verteilung der API-Antwortzeiten (Export der Xano-Logs), fehlgeschlagene Login-Versuche (potenzielle Sicherheitsvorfälle) und Abo-Kündigungsrate (Stripe-Webhooks → Supabase → eine einfache Reporting-View). Richte wöchentliche automatisierte Reports ein, die diese Metriken per E-Mail an den Gründer senden, die meisten Probleme werden als Trendänderungen sichtbar, bevor sie zu Krisen werden.
Füge für SaaS-Apps über 5.000 MAU Uptime-Monitoring über Better Uptime oder Pingdom für deine kritischen Endpoints hinzu (Login, Kern-Workflow). Alarmiere Slack innerhalb von 2 Minuten nach einem Ausfall. Bei dieser Nutzerzahl erzeugt selbst ein 10-minütiger Ausfall während der Geschäftszeiten erhebliches Support-Volumen. Die Kosten für Uptime-Monitoring (20 bis 50 Euro pro Monat) sind trivial gerechtfertigt.
DSGVO-Compliance by Design
Für deutsche und österreichische SaaS-Unternehmen ist DSGVO-Compliance keine nachträgliche Überlegung, sie ist eine Voraussetzung für B2B-Verkäufe. Unsere Architektur macht das einfach.
Supabase EU-Hosting (Frankfurt): Alle Kundendaten bleiben in der EU. Aktiviere RLS für alle Tabellen: Datenisolierung wird auf Datenbankebene erzwungen. Implementiere Soft Delete statt Hard Delete: Halte Daten für potenzielle Auskunftsanfragen. Logge alle Datenzugriffe: Xano-Request-Logs erfüllen Dokumentationsanforderungen.
Für Mittelstandskunden mit Datenschutzbeauftragtem (DSB) ist die Fähigkeit, einen DPA (Auftragsverarbeitungsvertrag) zu liefern und die Datenflüsse klar zu dokumentieren, ein entscheidendes Kaufargument. Supabase bietet Standard-DPA-Vorlagen für EU-Kunden. <a href="/contact">Kontaktiere App Studio</a> für eine DSGVO-Architekturberatung.