Auth, Zahlungen und Datenbanken für Nicht-Programmierer erklärt

TL;DR: Auth, Zahlungen und Datenbanken sind die drei zentralen Infrastruktur-Bausteine jedes SaaS. Auth klärt, „wer ist dieser Nutzer und darf er das tun". Zahlungen klären, „Geld sicher einsammeln, ohne Kartennummern zu speichern". Datenbanken klären, „wo leben die Daten und wie bekommen wir sie zurück". Dieser Guide erklärt jeden Bereich in einfacher Sprache, zeigt die realistischen Optionen 2026 (Supabase Auth und Clerk für Auth, Stripe für Zahlungen, Supabase Postgres und Firebase für Datenbanken), wann man was wählt, und die Grundkonzepte, die Nicht-Programmierer verstehen müssen, um mit KI-App-Buildern selbstbewusst SaaS zu bauen.

Einführung

Wenn Sie als Nicht-Programmierer 2026 mit KI-App-Buildern SaaS bauen, tauchen in jedem Projekt drei Infrastruktur-Bausteine auf: Authentifizierung (Auth), Zahlungen und Datenbanken. Der KI-Builder übernimmt den Großteil der Integration; Sie schreiben keinen Code. Aber Sie treffen Entscheidungen — welcher Auth-Anbieter, welches Zahlungsmodell, welche Datenbankstruktur. Diese Entscheidungen haben reale Konsequenzen für Ihr Produkt, Ihre Kosten, Ihre Sicherheit und Ihre künftige Flexibilität.

Die meisten Nicht-Programmierer-Guides überspringen die konzeptuelle Ebene komplett und behandeln diese Bausteine als Black Boxes. Das funktioniert, bis etwas kaputtgeht, Ihre Kosten unerwartet steigen oder Sie eine Entscheidung treffen müssen, die der KI-Builder von Ihnen bestätigt haben will. Zu verstehen, was jeder Baustein in einfacher Sprache tatsächlich tut, macht Sie zu einem besseren Operator — nicht zu einem codeschreibenden Engineer.

Dieser Guide erklärt jeden Baustein: was Auth/Zahlungen/Datenbanken tatsächlich tun, die realistischen Optionen 2026, wann man was wählt, die Grundkonzepte, die bei Entscheidungen auftauchen, und häufige Fehler von Nicht-Programmierern und wie man sie vermeidet.

Authentifizierung in einfacher Sprache erklärt

Authentifizierung ist, wie Ihre App weiß, wer sie gerade nutzt. Wenn ein Nutzer Ihr SaaS öffnet, muss die App zwei Fragen beantworten: Wer sind Sie (Authentifizierung) und was dürfen Sie tun (Autorisierung). Auth übernimmt beides.

Was zu Auth gehört

• Signup — Ein neues Konto mit E-Mail und Passwort (oder Social Login) anlegen
• Login — Identität verifizieren und eine Session erstellen
• Logout — Die Session beenden
• Passwort-Reset — Nutzern helfen, die ihr Passwort vergessen haben
• E-Mail-Verifizierung — Bestätigen, dass der Nutzer die E-Mail-Adresse besitzt, mit der er sich angemeldet hat
• Social Login — Anmeldung mit Google, Apple, GitHub usw.
• Multi-Faktor-Authentifizierung (MFA) — Zusätzliche Verifizierung über das Passwort hinaus
• Session-Management — Nutzer über Browser-Sessions hinweg eingeloggt halten
• Berechtigungen — Festlegen, worauf jeder Nutzer zugreifen darf (Admin vs. normaler Nutzer usw.)

Warum Sie Auth nicht selbst bauen

• Auth hat viele Edge Cases, die Experten bereits gelöst haben
• Sicherheitslücken in selbstgebautem Auth sind häufig und gefährlich
• Passwort-Speicherung erfordert spezifische Techniken (bcrypt, argon2 — keine Klartext-Speicherung)
• Compliance-Anforderungen (DSGVO, SOC 2) verlangen bestimmte Auth-Muster
• Fertige Auth-Anbieter erledigen all das zuverlässig für 0–25 $/Monat im Indie-Maßstab

Die realistischen Auth-Optionen 2026

• Supabase Auth — Kostenlos mit Supabase-Postgres-Datenbank; auf derselben Plattform gebündelt
• Clerk — Dedizierter Auth-Anbieter; großzügiger Free Tier; reichhaltige Features
• Auth0 — Enterprise-Niveau; komplexe Preisgestaltung; für die meisten Indie-SaaS überdimensioniert
• NextAuth (Auth.js) — Open Source; selbst gehostet; technischer Setup-Aufwand
• Firebase Auth — Wenn Sie im Firebase-Ökosystem unterwegs sind

Was Sie wählen sollten

• Nutzen Sie Supabase als Datenbank: wählen Sie Supabase Auth (gebündelt, einfach, kostenlos)
• Wollen Sie reichhaltiges Nutzer-Management (Organisationen, Teams, Rollen): wählen Sie Clerk
• Enterprise-Compliance-Anforderungen: wählen Sie Auth0
• Standard für neue Indie-SaaS: Supabase Auth (funktioniert mit den meisten KI-App-Buildern)

Auth-Konzepte, die Nicht-Programmierer kennen sollten

• JWT (JSON Web Token) — Ein kleines verschlüsseltes Token, das Identität beweist; Auth-Anbieter erzeugen diese
• Session — Eine konkrete Login-Instanz; Sessions laufen ab und müssen erneuert werden
• OAuth — Ein Protokoll für „Anmelden mit Google/Apple/etc."
• Magic Link — Login über einen angeklickten E-Mail-Link, ohne Passwort
• MFA / 2FA — Multi-Faktor-Authentifizierung; erhöht die Sicherheit über das Passwort hinaus
• Row-Level Security (RLS) — Regeln auf Datenbankebene, die sicherstellen, dass Nutzer nur ihre eigenen Daten sehen

Zahlungen in einfacher Sprache erklärt

Zahlungen sind, wie Ihr SaaS Geld von Kunden einsammelt. Die Herausforderung: Sie dürfen Kreditkartennummern nicht selbst speichern (Compliance-Gründe, Sicherheitsrisiko, sehr teuer). Sie nutzen einen Zahlungsdienstleister, der die Kartendaten verarbeitet; Sie erhalten eine Bestätigung, dass die Zahlung erfolgreich war.

Was zu Zahlungen gehört

• Checkout — Die Seite, auf der Kunden Zahlungsinformationen eingeben
• Abo-Management — Wiederkehrende Belastungen (monatlich, jährlich)
• Einmalzahlungen — Einzelne Transaktionen
• Speicherung von Zahlungsmethoden — Karten für künftige Belastungen speichern (das übernimmt der Dienstleister, nicht Sie)
• Rückerstattungen — Zahlungen bei Bedarf rückgängig machen
• Umgang mit fehlgeschlagenen Zahlungen — Belastungen erneut versuchen, wenn Karten abgelehnt werden
• Steuerbehandlung — Umsatzsteuer/Mehrwertsteuer berechnen und abführen
• Rechnungsstellung — Quittungen und Rechnungen erzeugen
• Umgang mit Reklamationen — Chargebacks verwalten, wenn Kunden Belastungen anfechten

Warum Sie Stripe nutzen und nichts Eigenes bauen

• PCI-DSS-Compliance ist Pflicht, um Kartendaten zu verarbeiten — teuer und komplex
• Stripe übernimmt die Compliance; Sie fassen keine Kartennummern an
• Betrugserkennung erfordert ausgefeilte ML-Modelle
• Wiederkehrende Abrechnung hat viele Edge Cases (abgelehnte Karten, Proration, Rückerstattungen)
• Stripes APIs und Tools sind ausgereift und gut dokumentiert

Die realistischen Zahlungsoptionen 2026

• Stripe — Standardwahl; funktioniert in den meisten Ländern; reichhaltige Features; ~2,9 % + 0,30 $ pro Transaktion
• Paddle — Merchant of Record (übernimmt die Steuer für Sie); typischerweise 5 % + 0,50 $; nützlich für globale SaaS
• Lemon Squeezy — Ähnlich wie Paddle; Merchant of Record; indie-freundlich
• PayPal — Ergänzende Zahlungsoption, die manche Kunden bevorzugen; zusätzlich zu Stripe

Was Sie wählen sollten

• Standard für SaaS: Stripe (am flexibelsten, gut unterstützt von KI-App-Buildern)
• Globales SaaS ohne Steuerregistrierung in vielen Jurisdiktionen: Paddle oder Lemon Squeezy
• Als zweite Option zu Stripe hinzufügen: PayPal

Abo vs. Einmalzahlung

• Abo: Kunde zahlt monatlich oder jährlich; erneuert sich automatisch; der SaaS-Standard
• Einmalig: Kunde zahlt einmal; einmalige Produkte, Lifetime-Deals
• Gestaffelte Abos: mehrere Pläne zu unterschiedlichen Preisen mit unterschiedlichen Features
• Nutzungsbasiert: Abrechnung nach Verbrauch (API-Aufrufe, Speicher usw.)
• Hybrid: Basis-Abo + nutzungsabhängige Mehrkosten

Stripe Connect für Marktplätze

• Nutzen Sie Stripe Connect, wenn Geld über Ihre Plattform an andere Parteien fließt
• Kunde zahlt an die Plattform; die Plattform zieht eine Provision ab; der Rest geht an Verkäufer/Anbieter
• Jeder Verkäufer durchläuft das Onboarding via Stripe Express (KYC, Bankdaten)
• Deutlich komplexer als einfaches Stripe; für Marktplätze aber notwendig

Zahlungskonzepte, die Nicht-Programmierer kennen sollten

• Webhook — Stripe sendet Benachrichtigungen an Ihre App, wenn Zahlungen erfolgreich sind oder fehlschlagen
• Customer Portal — Von Stripe gehostete Seite, auf der Kunden ihre Abos verwalten
• Testphase — Kostenlose Zeit, bevor die Abrechnung beginnt
• Proration — Anpassung der Belastungen, wenn Kunden mitten in der Periode upgraden/downgraden
• Dunning — Prozess, um fehlgeschlagene Zahlungen erneut zu versuchen und Umsatz zurückzuholen
• Chargeback — Kunde ficht eine Belastung bei seiner Bank an; der Dienstleister erstattet zurück
• MRR (Monthly Recurring Revenue) — Standard-SaaS-Kennzahl; Summe der monatlichen Abos
• Churn — Kunden, die kündigen; das Gegenteil von Wachstum

Datenbanken in einfacher Sprache erklärt

Datenbanken speichern die Daten Ihrer App. Jede Information, die sich Ihre App merken muss — Nutzerkonten, von Nutzern erstellte Inhalte, Einstellungen, Transaktionen, alles — lebt in einer Datenbank.

Was zu Datenbanken gehört

• Tabellen — Wo Daten leben, wie Tabellenkalkulationen mit benannten Spalten
• Zeilen (Rows) — Einzelne Datensätze in einer Tabelle (ein Nutzer, ein Beitrag usw.)
• Beziehungen (Relationships) — Wie Tabellen miteinander verbunden sind (ein Nutzer hat viele Beiträge)
• Queries — Die Datenbank nach bestimmten Daten fragen
• Indexe — Spezielle Strukturen, die Abfragen schnell machen
• Transaktionen — Gruppen von Änderungen, die gemeinsam gelingen oder scheitern
• Backups — Kopien der Daten für den Fall, dass etwas schiefgeht
• Migrationen — Änderungen an der Datenbankstruktur im Laufe der Zeit

Zwei große Datenbank-Kategorien

Relationale Datenbanken (Postgres, MySQL, SQLite) speichern Daten in Tabellen mit Beziehungen. Industriestandard für die meisten SaaS. Hervorragend für strukturierte Daten, komplexe Abfragen, Transaktionen, Zuverlässigkeit auf Finanzniveau.

Dokumentenorientierte Datenbanken (MongoDB, Firebase Firestore) speichern Daten als Dokumente (ähnlich wie JSON). Weniger starre Struktur. Einfacher, wenn die Datenstruktur stark variiert. Für typisches SaaS weniger verbreitet.

Die realistischen Datenbank-Optionen 2026

• Supabase (Postgres) — Standard für KI-App-Builder; bündelt Auth, Storage, Edge Functions; großzügiger Free Tier; die beliebteste Wahl
• Firebase (Firestore) — Googles Angebot; dokumentenorientierte Datenbank; enge Integration ins Google-Ökosystem
• PlanetScale (MySQL) — Ausgereiftes MySQL mit serverlosem Skalieren
• Neon (Postgres) — Serverloses Postgres; Konkurrent zu Supabase auf der Datenbankebene
• MongoDB Atlas — Dokumentenorientierte Datenbank; ausgereift; für typisches SaaS weniger verbreitet

Was Sie wählen sollten

• Standard für neues SaaS 2026: Supabase (Postgres + Auth + Storage + Edge Functions in einem)
• Wenn Sie gezielt das Google-Ökosystem wollen: Firebase
• Die meisten KI-App-Builder setzen standardmäßig auf Supabase; denken Sie nicht zu viel darüber nach

Datenbank-Konzepte, die Nicht-Programmierer kennen sollten

• Schema — Die Struktur Ihrer Datenbank (welche Tabellen existieren, welche Spalten sie haben)
• Migration — Eine Änderung am Schema (eine Spalte hinzufügen usw.)
• Foreign Key — Eine Spalte, die auf eine andere Tabelle verweist (user_id in einem Beitrag, verlinkt zur Nutzertabelle)
• Index — Macht bestimmte Abfragen schnell; der Trade-off sind etwas langsamere Schreibvorgänge
• Row-Level Security (RLS) — Regeln, die sicherstellen, dass Nutzer nur ihre eigenen Daten sehen
• Backup — Schnappschuss der Daten; sollte mindestens täglich erfolgen
• ORM — Werkzeug, mit dem Code mit der Datenbank interagiert (Prisma, Drizzle)
• Connection Pool — Limit für gleichzeitige Datenbankverbindungen; kann ausgeschöpft werden

Wie die drei Bausteine zusammenspielen

Wenn sich ein Nutzer anmeldet: Auth erstellt ein Konto; die Datenbank speichert den Nutzerdatensatz. Wenn ein Nutzer ein Abo abschließt: Stripe zieht die Zahlung ein; ein Webhook aktualisiert den Abo-Status in der Datenbank; Auth nutzt den Abo-Status für Berechtigungen. Wenn ein Nutzer auf ein Feature zugreift: Auth identifiziert ihn; die Datenbankabfrage liefert seine Daten, gefiltert durch RLS. Die drei Bausteine sind das Rückgrat jedes SaaS.

Typischer SaaS-Ablauf

• Nutzer klickt auf „Registrieren" → Auth erstellt ein Konto → Datenbank speichert den Nutzerdatensatz
• Nutzer klickt auf „Abonnieren" → Stripe Checkout → Stripe sendet einen Webhook → Datenbank aktualisiert den Abo-Status
• Nutzer meldet sich an → Auth verifiziert die Zugangsdaten → Gibt ein JWT zurück → Nutzer-Session ist aktiv
• Nutzer öffnet das Dashboard → Datenbankabfrage mit der Nutzer-ID → RLS filtert auf seine Daten → Anzeige
• Nutzer kündigt das Abo → Stripe Customer Portal → Webhook → Datenbank aktualisiert → Auth schränkt den Zugriff ein

Der realistische Stack für Indie-SaaS 2026

• Auth: Supabase Auth (kostenlos)
• Zahlungen: Stripe (~2,9 % + 0,30 $ pro Transaktion)
• Datenbank: Supabase Postgres (Free Tier deckt die meisten Indie-SaaS ab)
• Hosting: Vercel für Next.js (Free Tier für Hobbyprojekte; kostenpflichtig mit wachsendem Umfang)
• E-Mail: Resend (Free Tier; 20 $/Monat für 50K/Monat)
• Gesamt-Infrastrukturkosten im Indie-Maßstab: 0–50 $/Monat (der Großteil wird von Nutzern über Stripe-Gebühren getragen)

Häufige Fehler von Nicht-Programmierern

• Komplexes Auth (Auth0) wählen, wenn Supabase Auth reichen würde — Überbezahlt, überengineert, langsamer beim Launch.
• Firebase Auth + Supabase-Datenbank kombinieren — Der Auth-Anbieter sollte wo möglich zur Datenbank passen.
• E-Mail-Verifizierung überspringen — Nutzer mit unverifizierten E-Mails erzeugen später Support-Aufwand.
• RLS in Supabase nicht einrichten — Ohne RLS können Nutzer potenziell die Daten anderer Nutzer sehen. Kritische Sicherheitslücke.
• Kartennummern speichern — Das ist Ihnen rechtlich nicht erlaubt. Stripe verwaltet Karten; Sie speichern nur Kunden-IDs.
• Webhooks überspringen — Ohne Stripe-Webhooks wissen Sie nicht, wann Abos erfolgreich sind oder fehlschlagen.
• Steuerbehandlung vergessen — Umsatzsteuer-/Mehrwertsteuerpflichten variieren je nach Jurisdiktion.
• Keine Datenbank-Backups — Supabase sichert standardmäßig; Aufbewahrungsdauer prüfen und festlegen.
• Abo-Status vom Auth-Status abdriften lassen — Wenn das Abo endet, sollte sich das in Auth widerspiegeln.
• Nach Hype auswählen — Supabase gewinnt für die meisten Indie-SaaS. Denken Sie nicht zu viel darüber nach.

Sicherheitsgrundlagen, die Nicht-Programmierer verstehen müssen

• RLS (Row-Level Security) ist entscheidend — Ohne sie können Nutzer die Daten anderer sehen
• Umgebungsvariablen für Secrets — API-Keys gehören nie in Code, der auf GitHub committet wird
• Überall HTTPS — Modernes Hosting übernimmt das automatisch
• Strenge Passwort-Anforderungen — Mindest-Komplexität durchsetzen
• E-Mail-Verifizierung — Reduziert betrügerische Anmeldungen
• Rate Limiting auf Auth-Endpunkten — Verhindert Brute-Force-Angriffe (die meisten Auth-Anbieter übernehmen das)
• Backup-Verifizierung — Getestete Backups, nicht nur konfigurierte Backups
• Verifizierung der Stripe-Webhook-Signatur — Bestätigt, dass Webhooks tatsächlich von Stripe stammen

Häufig gestellte Fragen

F1: Muss ich das alles wirklich verstehen, wenn die KI es für mich baut? Grundverständnis: ja. Tiefe technische Umsetzung: nein. Die KI übernimmt die Umsetzung; Sie treffen Entscheidungen, für die Sie die Trade-offs verstehen müssen. Ohne Grundverständnis können Sie nicht bewerten, was Ihre KI gebaut hat, oder mit später eingestellten Engineers auf Augenhöhe sprechen.

F2: Was ist der Unterschied zwischen Supabase Auth und Clerk? Supabase Auth ist mit Supabase Postgres gebündelt — kostenlos und einfach, weniger Features. Clerk ist ein dediziertes Auth-Produkt — großzügiger Free Tier, reichhaltigere Features (Organisationen, Teams, Rollen, fortgeschrittenes Session-Management). Wählen Sie Clerk, wenn Sie umfassendes Nutzer-Management brauchen; sonst Supabase Auth.

F3: Warum ist Stripe immer die Antwort? Stripe wurde zum Indie-SaaS-Standard wegen API-Qualität, Dokumentation, Developer Experience und globaler Abdeckung. Konkurrenten gibt es (Paddle, Lemon Squeezy sind für bestimmte Anwendungsfälle gut), aber Stripe ist die sichere Standardwahl.

F4: Was ist mit internationalen Zahlungen und Währungen? Stripe unterstützt mehrere Währungen. Für Umsatzsteuer-/Steuerbehandlung, ohne sich in vielen Jurisdiktionen registrieren zu müssen, agieren Paddle und Lemon Squeezy als Merchant of Record. Trade-off: höhere Transaktionsgebühren im Austausch für steuerliche Vereinfachung.

F5: Wann ist Postgres nicht die richtige Wahl? Für typisches SaaS selten. Dokumentenorientierte Datenbanken (Firebase Firestore, MongoDB) funktionieren besser, wenn die Datenstruktur zwischen Datensätzen stark variiert. Für die meisten SaaS deckt Postgres 95 % der Anforderungen besser ab als Alternativen.

F6: Was, wenn ich den Free Tier von Supabase überschreite? Die kostenpflichtigen Supabase-Stufen (25 $/Monat + Nutzung) decken erhebliche Skalierung ab. Darüber hinaus gibt es Optionen wie Self-Hosting von Supabase oder Migration zu verwalteten Postgres-Anbietern (Neon, Railway, AWS RDS). Die meisten SaaS wachsen nie über Supabase hinaus.

F7: Woher weiß ich, ob mein KI-gebauter Code Auth/Zahlungen/Datenbanken korrekt handhabt? Testen Sie die offensichtlichen Abläufe selbst. Registrieren. Abonnieren. Anmelden. Kündigen. Erstatten. Testen Sie die Datenisolierung (kann Nutzer A die Daten von Nutzer B sehen? — sollte nicht der Fall sein). Wenn viel auf dem Spiel steht, bezahlen Sie vor dem Launch für ein Engineering-Audit.

Fazit

• Drei Infrastruktur-Bausteine braucht jedes SaaS: Auth (wer darf was tun), Zahlungen (Geld sicher einsammeln), Datenbanken (wo Daten leben). KI-App-Builder integrieren sie; Sie treffen die Entscheidungen.
• Realistischer Stack für Indie-SaaS 2026: Supabase Auth (kostenlos), Stripe für Zahlungen (~2,9 % + 0,30 $), Supabase-Postgres-Datenbank (Free Tier deckt das meiste ab). Gesamte Infrastrukturkosten: 0–50 $/Monat im Indie-Maßstab.
• Schlüsselkonzepte zum Verstehen: JWT, RLS, Webhooks, MRR, Churn, Schema/Migration, OAuth, MFA. Erfordert kein Coding, um sie zu verstehen; ist aber nötig für informierte Entscheidungen.
• Häufige Fehler: RLS überspringen, keine Webhooks, gemischte Anbieter, keine E-Mail-Verifizierung, Backups nicht geprüft. Die KI baut; Sie prüfen und entscheiden.

Wenn Sie als Nicht-Programmierer mit KI-App-Buildern SaaS bauen, müssen Sie keinen Code schreiben, aber Sie müssen verstehen, was der Code auf konzeptueller Ebene tut. Auth bedeutet „wer darf was tun". Zahlungen bedeutet „Geld sicher einsammeln, ohne Karten anzufassen". Datenbanken bedeutet „wo Daten leben und wie man sie zurückbekommt". Der realistische Stack für Indie-SaaS 2026 ist Supabase Auth + Stripe + Supabase Postgres. Wählen Sie diesen Stack standardmäßig; verkomplizieren Sie es nicht. Verstehen Sie die oben genannten Grundkonzepte; prüfen Sie, dass Ihr KI-gebauter Code sie korrekt handhabt; holen Sie sich Engineering-Urteilsvermögen ins Boot, wenn mehr auf dem Spiel steht. Die Kombination aus KI-App-Buildern, grundlegendem Infrastrukturverständnis und guter operativer Disziplin ist, wie Nicht-Programmierer 2026 erfolgreich echte SaaS bauen.