Kann eine No-Code-SaaS-Architektur wirklich 100.000 monatlich aktive Nutzer handhaben?

Ja. WeWeb + Xano + Supabase PostgreSQL sind für diese Skalierung konzipiert. Supabase PostgreSQL verwaltet Milliarden von Zeilen; Xano skaliert horizontal; WeWeb wird über CDN geliefert. Das Kritische ist korrektes Datenmodellieren mit Indizes und Row-Level-Security von Tag eins — die Architektur selbst ist nicht der Engpass.

Warum ist Separation of Concerns in einem No-Code-Stack wichtiger als in einem traditionellen Stack?

In All-in-One-Plattformen wie Bubble sind Frontend und Backend eng gekoppelt, was es unmöglich macht, Schichten unabhängig zu skalieren. Mit WeWeb + Xano + Supabase kannst du die API-Schicht skalieren, ohne das Frontend anzufassen, die Datenbank wechseln ohne Geschäftslogik neu zu schreiben, und eine Schicht nach der anderen migrieren — genau wie Enterprise-Architektur auf AWS oder GCP, aber mit No-Code-Tools.

Wie erklärt man No-Code-Architektur technischen Investoren wie HV Capital oder Earlybird?

Betone, dass es Standard-PostgreSQL ist (kein proprietärer Lock-in), REST-APIs (Industriestandard) und jede Schicht unabhängig ausgetauscht werden kann. WeWeb kann durch ein React-Frontend ersetzt werden, Xano durch ein Node.js-Backend, Supabase durch jeden PostgreSQL-Host. Daten werden mit Standard-SQL-Dump exportiert. Das ist eine Antwort, die bei technisch versierten Investoren stark resoniert.

Welche deutschen Business-Integrationen sollten in der Xano-Schicht für ein B2B-SaaS sein?

Die häufigsten für den deutschen Markt: DATEV und Lexoffice (Buchhaltung), BankID via Proxy-API (Authentifizierung), Klarna (Zahlungen), E-Rechnungsformaten (ZUGFeRD/XRechnung für öffentlichen Sektor) und Brevo oder Sendgrid (Transaktions-E-Mails). Alle diese Integrationen in Xano als separate Utility-Funktionen zu halten, ermöglicht unabhängige Updates ohne das Frontend anzufassen.

No-Code SaaS Architektur für 100.000 Nutzer

Die Kernarchitektur: Separation of Concerns

Der größte Fehler bei No-Code-SaaS ist die Nutzung einer All-in-One-Plattform (Bubble, Glide), bei der Frontend und Backend eng gekoppelt sind. Das verursacht in der Skalierung drei Probleme: Performance verschlechtert sich, weil du Frontend und Backend nicht unabhängig skalieren kannst, deine Daten sind in der Plattform eingesperrt, und du kannst jede Schicht nicht separat optimieren.

Die richtige Architektur trennt Zuständigkeiten: - Frontend: WeWeb (CDN-geliefert, unabhängig skalierbar) - Geschäftslogik: Xano (horizontal skalierbare API) - Datenbank: Supabase (verwaltetes PostgreSQL, skaliert auf Milliarden Zeilen) - Automatisierung: Make oder n8n (asynchrone Jobs, Webhooks, Benachrichtigungen)

Das ist dieselbe Trennung, die technische Teams verwenden, die SaaS auf AWS oder GCP bauen — aber mit No-Code-Tools statt custom Code. Für deutsche SaaS-Unternehmen, die Enterprise-Kunden ansprechen, ist diese Architektur auch ein starkes Argument bei Sicherheitsüberprüfungen: jede Schicht kann unabhängig geprüft und validiert werden, und Daten werden in Standard-PostgreSQL ohne proprietären Lock-in gespeichert.

Die Datenbankschicht: PostgreSQL mit RLS

Dein Datenmodell ist die wichtigste Architekturentscheidung. Mach es richtig und Skalierung ist einfach. Mach es falsch und du musst neu bauen.

Schlüsselprinzipien für eine skalierbare No-Code-SaaS-Datenbank: 1. Jede Tabelle hat created_at, updated_at und einen Primärschlüssel (bigserial) 2. Multi-Tenant via workspace_id Fremdschlüssel auf jeder Tabelle 3. Row-Level-Security-Policies auf jeder nutzerorientierten Tabelle 4. Indizes auf workspace_id, user_id, status, created_at 5. Speichere niemals berechnete Werte in der Datenbank — berechne in Xano

Supabase PostgreSQL handhabt das ausgezeichnet. RLS-Policies bedeuten, dass deine API-Endpunkte nicht versehentlich die Daten eines anderen Tenants zurückgeben können — die Datenbank erzwingt Isolation. Aus DSGVO- und Schrems-II-Perspektive ist das ein starkes Argument für deutsche B2B-Kunden: Datenzugriffskontrolle ist auf Datenbankebene garantiert, nicht nur auf Anwendungsebene — eine Anforderung, die viele DSBs (Datenschutzbeauftragte) bei der Lieferantenevaluierung stellen.

Die API-Schicht: Xano Geschäftslogik

Xano sitzt zwischen deinem Frontend und deiner Datenbank. Jede Nutzeraktion läuft durch einen Xano-Endpunkt, nicht direkt zu Supabase. Das gibt dir: - Eingabevalidierung vor dem Datenbank-Hit - Geschäftslogik (Preisberechnungen, Zustandsmaschinen, Berechtigungsprüfungen) - Drittanbieter-Integrationen (Stripe, SendGrid, Twilio) an einer Stelle - Audit-Protokollierung auf API-Ebene

Strukturiere deine Xano-Endpunkte RESTfully: GET /workspaces/:id/projects, POST /projects, PATCH /projects/:id. Vermeide RPC-Style-Endpunkte. Halte Endpunkte klein und zusammensetzbar.

Ein Muster, das wir konsequent verwenden: erstelle "Utility"-Funktionen in Xano pro externem Service — z.B. "Stripe-Abbuchung senden" oder "Willkommens-E-Mail senden via Brevo". Rufe dann diese Utilities aus deinem Geschäftslogik-Stack auf. Das hält den Code sauber und erleichtert Updates. Für deutsche SaaS-Unternehmen sind häufige Integrationen DATEV (Buchhaltung), Lexoffice, ELSTER (Steuern), Klarna (Zahlungen) und BankID — Xano handhabt all diese ohne Spezialcode.

Die Frontend-Schicht: WeWeb Performance

WeWeb generiert eine echte Webanwendung: statisches HTML/CSS/JS, über CDN geliefert, mit dynamischen Daten, die über REST-API-Aufrufe abgerufen werden. Das bedeutet: - Erster Ladevorgang ist schnell (CDN-gecachte statische Assets) - Daten laden asynchron (kein Server-Side-Rendering-Flaschenhals) - Frontend skaliert unbegrenzt (es sind nur Dateien auf einem CDN)

Für Performance bei Skalierung: paginiere alle Listen-Abfragen (max. 50 Elemente pro Seite), nutze WeWebs eingebautes Caching für statische Daten und lazy-lade schwere Komponenten.

Ein unterschätzter Vorteil: WeWeb generiert echtes HTML, was bedeutet, dass deine Marketing-Seiten und öffentlichen Seiten von Google korrekt indexiert werden. Für deutsche SaaS-Unternehmen, die auf SEO für Kundengewinnung setzen — eine übliche Strategie auf dem deutschen Markt, wo Anzeigenpreise hoch sind — ist das ein entscheidender Vorteil gegenüber Bubble, dessen Lighthouse-Scores auf Mobile typischerweise bei 40–55 landen.

Authentifizierung und Multi-Tenancy

Nutze Supabase Auth für Benutzerauthentifizierung — battle-tested und kostenlos im Free-Tier. Der Flow: 1. Nutzer registriert sich/meldet sich an via Supabase Auth 2. Supabase stellt ein JWT mit user_id und workspace_id aus 3. WeWeb speichert JWT, sendet es mit jeder Xano API-Anfrage 4. Xano validiert JWT und extrahiert Nutzerkontext 5. Datenbank-RLS-Policies nutzen auth.uid() zur Erzwingung der Zeilen-Isolation

Für Multi-Tenancy: erstelle eine workspaces-Tabelle, eine workspace_members-Tabelle (user_id, workspace_id, role) und sende workspace_id mit jeder API-Anfrage. Xano verifiziert Mitgliedschaft vor jeder Operation.

Vergiss nicht Edge Cases: was passiert, wenn ein Nutzer Mitglied mehrerer Workspaces ist? Wie handhabst du E-Mail-Einladungen? Diese Muster sind bekannt und dokumentiert — erfinde das Rad nicht neu.

Wann zu custom Code upgraden?

Diese Architektur skaliert komfortabel auf 100.000 MAU für die meisten SaaS-Typen. Darüber hinaus können spezifische Engpässe auftreten:

- Sehr hoher Schreib-Throughput (>1.000 Schreibvorgänge/Sekunde): Supabase verwaltetes PostgreSQL könnte dedizierte Compute benötigen - Komplexe Echtzeit-Features (Multiplayer, Live-Kollaboration): eigene WebSocket-Infrastruktur könnte sinnvoller sein - Custom LLM-Inferenz: selbst gehostete Modelle erfordern eigene Infrastruktur

Für 95 % der SaaS-Produkte ist diese Architektur in jeder Skalierung mehr als ausreichend. Und wenn du eine Schicht migrieren musst, kannst du das tun — deine Daten sind in Standard-PostgreSQL, deine API ist REST, dein Frontend-Code gehört dir.

Das ist ein wichtiges Argument für deutsche SaaS-Unternehmen, die planen, an HV Capital, Earlybird, Northzone oder ähnliche Investoren zu verkaufen, die technische Due-Diligence-Fragen stellen. Die Architektur hat keinen proprietären Lock-in — jede Schicht kann unabhängig ausgetauscht werden.