Der Leitfaden des nicht-technischen Gründers für Backend, Datenbank und Authentifizierung

TL;DR: Nicht-technische Gründer müssen 2026 nicht programmieren lernen, um echte Software zu launchen, aber sie müssen drei Konzepte gut genug verstehen, um KI-Builder effektiv zu prompten --- Backend, Datenbank und Auth. Dieser Leitfaden erklärt jedes davon in einfacher Sprache. Das Backend ist der Teil Ihrer App, den Nutzer nicht sehen, der aber die Arbeit erledigt. Die Datenbank ist, wo die Informationen Ihrer App leben. Auth ist, wie die App weiß, wer jemand ist und was er darf. Sie müssen nichts davon selbst schreiben; Sie müssen genug wissen, um es korrekt zu prompten.

Einführung

Nicht-technische Gründer können 2026 echte Software launchen, ohne programmieren zu lernen. Moderne KI-Builder wie Greta übernehmen die Umsetzung. Aber die Prompts, die Sie schreiben, bestimmen den Output, den Sie bekommen, und die Prompts, die saubere Apps produzieren, erfordern grundlegende konzeptionelle Kompetenz in drei Dingen: Backend, Datenbank und Auth. Nicht tiefes technisches Wissen --- konzeptionelle Kompetenz. Der Unterschied zwischen "ein Nutzer hat einen Namen und eine E-Mail" und "User-Tabelle mit Feldern id uuid, name text, email text unique" hat nichts mit Coding-Skills zu tun. Es geht darum, die Konzepte gut genug zu kennen, um zu beschreiben, was Sie wollen.

Dieser Leitfaden erklärt jedes Konzept in einfacher Sprache, mit konkreten Beispielen und dem spezifischen Wissen, das Sie brauchen, um KI-Builder effektiv zu prompten. Am Ende können Sie das Datenmodell für jedes SaaS beschreiben, das Sie bauen möchten --- nicht weil Sie programmieren gelernt haben, sondern weil Sie gelernt haben, so über Software nachzudenken, wie sie tatsächlich funktioniert.

Warum genau diese drei Konzepte

Software hat viele Konzepte. Caching, Queues, Microservices, Load Balancer, CDNs, Edge Functions --- die Liste geht weiter. Für die meisten nicht-technischen Gründer, die SaaS launchen, können Sie die meisten davon getrost ignorieren. KI-Builder übernehmen sie mit Standardentscheidungen, die gut funktionieren.

Drei Konzepte sind anders. Backend, Datenbank und Auth tauchen in fast jedem Prompt auf, den Sie schreiben werden. Sie falsch zu verstehen, produziert Output, der auf offensichtliche Weise kaputt ist. Sie richtig zu verstehen, schaltet dramatisch besseren KI-Builder-Output frei.

Konzept 1: Das Backend (was Nutzer nicht sehen)

Wenn Sie eine SaaS-App in Ihrem Browser öffnen, sehen Sie Screens --- Login-Formular, Dashboard, Einstellungen usw. Diese Screens sind das Frontend. Das ist, was in Ihrem Browser gerendert wird.

Das Backend ist der Teil der App, der irgendwo auf einem Server läuft und die ganze Arbeit erledigt, die Nutzer nicht sehen. Wenn Sie auf "Anmelden" klicken, sendet das Frontend Ihre E-Mail und Ihr Passwort an das Backend. Das Backend prüft, ob das Passwort korrekt ist, sucht Ihr Konto und sendet die Daten zurück, die das Frontend braucht, um Ihr Dashboard zu zeigen.

Konkretes Beispiel. Wenn Sie eine neue Aufgabe in einer To-do-App speichern:

• Frontend: Sie tippen "Einkaufen gehen", klicken auf Speichern. Das Frontend erfasst, was Sie eingegeben haben.
• Backend: Empfängt den Aufgabentext und Ihre User-ID. Validiert die Eingabe (nicht leer, nicht zu lang). Fügt einen neuen Task-Datensatz in die Datenbank ein. Gibt die gespeicherte Aufgabe an das Frontend zurück.
• Frontend: Empfängt die gespeicherte Aufgabe. Aktualisiert die sichtbare Liste, um sie anzuzeigen. Schließt das Eingabeformular.

Was Sie als nicht-technischer Gründer wissen müssen: Das Backend ist dort, wo Business-Logik, Validierung und Datenbank-Interaktion stattfinden. Wenn Sie prompten "Nutzer können Aufgaben erstellen", baut die KI sowohl das Frontend (das Eingabeformular) als auch das Backend (die Logik, die es speichert).

Backend-Entscheidungen, die KI-Builder automatisch treffen

• Server-Framework --- Moderne KI-Builder verwenden sinnvolle Standards (Next.js, Remix oder Ähnliches)
• API-Stil --- Meist REST oder RPC; zählt weniger, als man denkt
• Hosting --- In der Plattform gebündelt (Vercel für v0, Gretas Hosting für Greta, Bolt Cloud für Bolt)
• Fehlerbehandlung --- Standardmuster; wenn Sie spezifisches Handling wollen, prompten Sie es explizit
• Rate Limiting --- KI-Builder fügen dies meist für sensible Endpoints hinzu

Diese Entscheidungen müssen Sie generell nicht selbst treffen. Sie müssen aber wissen, dass sie existieren, damit die Standardentscheidungen der KI für Sie Sinn ergeben, wenn sie auftauchen.

Konzept 2: Die Datenbank (wo Informationen leben)

Die Datenbank ist, wo die Informationen Ihrer App dauerhaft gespeichert werden. Wenn Sie sich registrieren, landen Ihre Kontoinformationen in der Datenbank. Wenn Sie eine Aufgabe erstellen, landet die Aufgabe in der Datenbank. Wenn Sie sich nächste Woche wieder anmelden, findet die App Ihre Daten in der Datenbank und zeigt sie Ihnen wieder.

Datenbanken speichern Informationen in Tabellen. Eine Tabelle ist wie eine Tabellenkalkulation --- Zeilen und Spalten. Jede Zeile ist ein Datensatz (ein Nutzer, eine Aufgabe, eine Bestellung). Jede Spalte ist eine Information (der Name des Nutzers, der Text der Aufgabe, der Betrag der Bestellung).

Konkretes Beispiel. Eine einfache To-do-App könnte zwei Tabellen haben:

Beachten Sie das Feld user_id in der Task-Tabelle. So verbindet die Datenbank Aufgaben mit Nutzern. Wenn Sie sich anmelden, schaut sich die App Ihre User.id an, findet dann alle Task-Datensätze, bei denen user_id mit Ihrer User.id übereinstimmt, und zeigt Ihnen diese Aufgaben.

Feldtypen (der Teil, den die meisten Gründer überspringen)

Jede Spalte hat einen Typ --- text, number, true/false (boolean), date usw. Typen zählen, weil sie bestimmen, welche Art von Daten die Spalte aufnehmen kann.

• uuid --- Eine eindeutige Kennung. Verwendet für die id-Spalte jeder Tabelle.
• text --- Wörter, Sätze, Absätze. Verwenden Sie es für Namen, Beschreibungen, E-Mails.
• int --- Ganze Zahlen. Verwenden Sie es für Zählungen, Mengen.
• decimal --- Zahlen mit Nachkommastellen. Verwenden Sie es für Preise, Prozentsätze.
• boolean --- Wahr oder falsch. Verwenden Sie es für Ja/Nein-Flags (completed, active, verified).
• timestamp --- Datum und Uhrzeit. Verwenden Sie es für created_at, updated_at, scheduled_for.
• jsonb --- Flexible strukturierte Daten. Sparsam verwenden; nur wenn die Struktur variiert.

Wenn Sie einen KI-Builder prompten, produziert das Benennen der Feldtypen dramatisch saubereren Output. "Eine Task hat text, completed und created_at" ist vage. "Task: id uuid, user_id uuid foreign key, text text, completed boolean default false, created_at timestamp default now()" ist konkret. Die KI hat jetzt ein echtes Schema, gegen das sie bauen kann.

Beziehungen zwischen Tabellen

Tabellen verbinden sich über Foreign Keys. Ein Foreign Key ist eine Spalte in einer Tabelle, die auf eine Zeile in einer anderen Tabelle zeigt. Im obigen Beispiel ist Task.user_id ein Foreign Key, der auf User.id zeigt.

Gängige Beziehungsmuster, denen Sie begegnen werden:

• Eins-zu-viele --- Ein Nutzer hat viele Aufgaben. Die Task-Tabelle hat eine user_id-Spalte.
• Viele-zu-viele --- Viele Nutzer können in vielen Projekten sein. Verwenden Sie eine "Join-Tabelle" (UserProject) mit sowohl user_id- als auch project_id-Spalten.
• Eins-zu-eins --- Weniger häufig. Ein Nutzer hat ein Profil.

Die meisten SaaS-Apps bestehen überwiegend aus Eins-zu-viele-Beziehungen. Beim Prompten hilft es, die Beziehung explizit zu benennen: "Task hat user_id (Foreign Key zu User.id) --- ein User hat viele Tasks."

Datenbankentscheidungen, die KI-Builder treffen

• Datenbanktyp --- Meist PostgreSQL via Supabase, MongoDB oder plattform-nativ.
• Indexierung --- KI-Builder fügen meist automatisch Indizes für häufig abgefragte Spalten hinzu.
• Backup --- In verwalteten Datenbankdiensten gebündelt.
• Migrationen --- KI-Builder übernehmen Migrationen, während Sie das Schema ändern.

Für die meisten SaaS-Apps müssen Sie keine Entscheidungen zur Datenbanktechnologie treffen. Sie müssen aber Entscheidungen zum Datenmodell treffen --- welche Tabellen existieren und welche Felder sie haben. Diese Entscheidungen liegen bei Ihnen; die KI setzt sie um.

Konzept 3: Auth (zu wissen, wer jemand ist)

Auth (kurz für Authentication und Authorization) ist, wie die App weiß, wer jemand ist und was er tun darf.

Authentifizierung beantwortet "wer bist du?" Wenn Sie sich mit Ihrer E-Mail und einem Magic Link oder Passwort anmelden, ist das Authentifizierung.

Autorisierung beantwortet "was darfst du tun?" Sobald die App weiß, wer Sie sind, muss sie entscheiden, welche Daten Sie sehen können, welche Aktionen Sie ausführen können und was vor Ihnen verborgen bleibt. Sie können Ihre eigenen Aufgaben sehen; die Aufgaben anderer Nutzer nicht.

Gängige Authentifizierungsmethoden

• E-Mail-Magic-Link --- Der Nutzer gibt seine E-Mail ein; die App schickt ihm einen Link per E-Mail; ein Klick auf den Link meldet ihn an. Einfach, sicher, kein Passwort zu merken. Am gängigsten für v1.
• E-Mail + Passwort --- Traditionell. Funktioniert, aber Nutzer vergessen Passwörter. Erfordert einen Passwort-Reset-Flow.
• Social Login --- Anmeldung mit Google, GitHub oder Ähnlichem. Reibungslos, wenn Ihre Nutzer bereits in diesen Ökosystemen sind.
• SSO (Single Sign-On) --- Enterprise-Feature. Nutzer melden sich über den Identity-Provider ihres Unternehmens an. Für B2B im großen Maßstab hinzufügen.

Für die meisten v1-SaaS ist Magic-Link-Auth der richtige Standard. Geben Sie es explizit in Ihrem Prompt an: "Füge E-Mail-Magic-Link-Authentifizierung hinzu. Neue Nutzer registrieren sich mit E-Mail; bestehende Nutzer erhalten einen Einmal-Link zur Anmeldung."

Autorisierungs-Grundlagen: Row-Level Security

Das wichtigste Autorisierungskonzept, das nicht-technische Gründer kennen sollten, ist Row-Level Security (RLS). RLS ist ein Datenbank-Feature, das kontrolliert, welche Zeilen jeder Nutzer sehen und ändern kann.

Ohne RLS: Wenn eine Query versehentlich einen Bug hat, könnte sie alle Zeilen einer Tabelle zurückgeben --- inklusive der Daten anderer Nutzer. Das ist der häufigste Sicherheitsfehler in vibe-gecodeten Apps.

Mit RLS: Die Datenbank selbst setzt durch, dass "dieser Nutzer nur Zeilen sehen kann, bei denen user_id seiner eigenen user.id entspricht". Selbst wenn eine Query fehlerhaft ist, stoppt die Datenbank das Leck.

Prompten Sie immer explizit für RLS: "Füge Row-Level Security hinzu, sodass jeder Nutzer nur seine eigenen Datensätze lesen und schreiben kann." Dieser eine Prompt verhindert die schlimmste Klasse von Vibe-Coding-Sicherheitsbugs.

Rollen und Berechtigungen

Die meisten v1-SaaS-Apps haben zwei Nutzertypen --- reguläre Nutzer und Admins. Admins können alle Daten sehen; reguläre Nutzer sehen ihre eigenen. Komplexere Apps haben mehr Rollen. Ein SaaS für Marketing-Agenturen könnte Agentur-Inhaber, Team-Mitglieder und Kunden haben --- jeweils mit unterschiedlichen Berechtigungen. Geben Sie Rollen explizit in Ihrem Datenmodell an: "User hat ein role-Feld mit den Werten owner/member/client."

Wie diese drei Konzepte zusammenspielen

Echtes Beispiel: Ein Nutzer erstellt eine Aufgabe in einer To-do-App.

1. Frontend erfasst die Eingabe --- Der Nutzer tippt "Einkaufen gehen", klickt auf Speichern.
2. Backend empfängt die Anfrage --- Enthält das Auth-Token des Nutzers (beweist, wer er ist).
3. Auth-Check --- Das Backend prüft, ob das Auth-Token gültig ist. Löst es zu user.id auf.
4. Validierung --- Das Backend prüft, ob der Aufgabentext nicht leer und nicht zu lang ist.
5. Datenbank-Insert --- Das Backend fügt eine neue Task-Zeile ein, wobei user_id auf die id des authentifizierten Nutzers gesetzt wird.
6. RLS-Check --- Die Datenbank bestätigt, dass der Nutzer eine Task mit dieser user_id einfügen darf.
7. Antwort --- Das Backend gibt die gespeicherte Aufgabe an das Frontend zurück.
8. Frontend aktualisiert --- Die sichtbare Aufgabenliste wird mit der neuen Aufgabe aktualisiert.

Jede SaaS-Interaktion funktioniert ungefähr so. Das Backend erledigt die Arbeit; die Datenbank speichert das Ergebnis; Auth stellt sicher, dass die Arbeit autorisiert war. KI-Builder übernehmen die Umsetzung; Sie geben das Datenmodell und die Auth-Anforderungen vor.

Alles in einem Prompt zusammenfügen

Schwacher Prompt

"Baue mir eine To-do-App, in der Nutzer Aufgaben hinzufügen und abschließen können. Mach sie sicher."

Was fehlt: kein Datenmodell, keine angegebene Auth-Methode, "mach sie sicher" ist zu vage. Die KI wird bei allem raten --- und viele Vermutungen werden falsch sein.

Starker Prompt

"Baue eine To-do-App. Datenbanktabellen: User (id uuid, email text unique, created_at timestamp). Task (id uuid, user_id uuid foreign key zu User.id, text text nicht leer, completed boolean default false, created_at timestamp). Auth: E-Mail-Magic-Link, kein Passwort. Füge Row-Level Security hinzu, sodass Nutzer nur ihre eigenen Aufgaben lesen und schreiben können. Nach der Anmeldung landet der Nutzer auf /dashboard, zunächst mit seinen unvollständigen Aufgaben, darunter die abgeschlossenen."

Der starke Prompt benennt die Tabellen, typisiert die Felder, spezifiziert die Beziehung, wählt die Auth-Methode, fordert RLS und beschreibt das nutzerseitige Verhalten. Die KI hat jetzt alles, was sie braucht, um beim ersten Versuch sauberen Output zu produzieren.

Häufige Backend-/Datenbank-/Auth-Fehler nicht-technischer Gründer

• Das Datenmodell im Prompt überspringen --- Vage Schemas produzieren chaotische Iterationen. Typisieren Sie Ihre Felder immer.
• Row-Level Security vergessen --- Ohne RLS leckt Ihre App Daten, sobald sich ein zweiter Nutzer anmeldet. Prompten Sie sie immer explizit.
• Passwort-Auth für v1 verlangen --- Passwort-Reset-Flows fügen Komplexität hinzu. Magic Link ist einfacher und sicherer.
• jsonb für alles verwenden --- Verlockend, weil flexibel, aber jsonb-Abfragen sind langsamer und schwieriger. Verwenden Sie richtige Spalten für Felder, die Sie abfragen.
• Foreign Keys überspringen --- Ohne sie kann die Datenbank Beziehungen nicht durchsetzen.
• Timestamps vergessen --- Fügen Sie immer created_at (und meist updated_at) zu jeder Tabelle hinzu.
• Nur Frontend-Validierung vertrauen --- Frontend-Validierung ist für die Nutzererfahrung; Backend-Validierung ist für die Sicherheit. Prompten Sie immer beides.
• Admin-Auth als "nur eine Rolle" bauen --- Admin-Aktionen sollten gezielt geloggt werden (admin_action_log).

Wann Sie mehr lernen müssen

Für die üblichen 80 % der SaaS-Apps reicht, was in diesem Leitfaden steht. Für einige spezifische Fälle brauchen Sie mehr Tiefe.

• Multi-Tenancy --- Wenn Ihre App Teams oder Organisationen bedient, wird das Datenmodell komplexer (Organization → Members → User).
• Sensible Daten --- Wenn Sie mit PII, Finanzdaten oder Gesundheitsinformationen arbeiten, holen Sie sich ein Engineering-Review speziell zu Auth und RLS.
• Echtzeit-Features --- Live-Updates, Präsenz, kollaboratives Editieren nutzen alle zusätzliche Infrastruktur.
• Background Jobs --- Lang laufende Aufgaben (Massen-E-Mails versenden, Uploads verarbeiten) laufen meist in Background-Queues.
• Individuelle Integrationen --- Die Integration mit spezifischen externen APIs (Salesforce, QuickBooks) braucht oft nuanciertere Prompts oder Engineering-Hilfe.

Wo die Wahl des KI-Builders zählt

Alle modernen KI-Builder handhaben Backend, Datenbank und Auth --- aber sie treffen unterschiedliche Entscheidungen darüber, welche Technologien sie einsetzen.

• Greta --- Multi-Backend (Supabase, MongoDB, AWS). Gebündeltes Growth-Tooling bedeutet, dass Auth, Datenbank und Hosting alle in einem Workspace sind. Gut für nicht-technische Gründer speziell, weil die Entscheidungen unsichtbar bleiben.
• Lovable --- Fester Stack (React + Tailwind + Supabase). Supabase übernimmt Datenbank, Auth, RLS und Echtzeit. Vorhersehbar; weniger flexibel.
• Bolt.new --- Browser-nativ via WebContainers. Nutzt Supabase oder andere Datenbanken per Prompt.
• v0 by Vercel --- Next.js + shadcn/ui. Nutzt Vercel Postgres oder Supabase.
• Replit --- Am flexibelsten. Volle Cloud-Linux-Umgebung; unterstützt jede Datenbank, jede Sprache, jedes Framework.

Häufig gestellte Fragen

F1: Muss ich 2026 wirklich nicht programmieren lernen? Für die üblichen 80 % der SaaS-Apps, nein. Sie brauchen aber konzeptionelle Kompetenz zu Backend, Datenbank und Auth --- das ist etwas anderes als Code zu schreiben.

F2: Wie viel muss ich tatsächlich über jedes Konzept wissen? Genug, um einen Prompt mit benannten Tabellen, typisierten Feldern, benannter Auth-Methode und expliziter RLS zu schreiben. Das ist ungefähr das, was in diesem Leitfaden steht.

F3: Was, wenn mein KI-Builder mich nicht nach Backend/Datenbank/Auth fragt? Die meisten KI-Builder wählen automatisch sinnvolle Standards. Aber Ihre Prompts sollten sie trotzdem explizit spezifizieren --- die Output-Qualität ist dramatisch höher, wenn das Datenmodell typisiert und Auth benannt ist.

F4: Woher weiß ich, ob mein Datenmodell richtig ist? Zwei Signale: (1) der KI-Builder produziert funktionierende Features beim ersten oder zweiten Prompt, (2) Features, die zusammenhängen sollten, tun das auch tatsächlich.

F5: Was ist der häufigste Fehler nicht-technischer Gründer? Row-Level Security überspringen. Apps funktionieren in der Entwicklung mit einem Test-Nutzer einwandfrei; sie lecken Daten, sobald sich ein zweiter Nutzer anmeldet. Prompten Sie immer explizit für RLS.

F6: Wann sollte ich mir Engineering-Hilfe holen? Wenn Sie regulierte Daten (HIPAA, PCI) verarbeiten, wenn Performance oder Skalierung zählt, wenn Sie tief mit Legacy-Systemen integrieren, oder wenn Zahlungsflüsse komplex werden.

F7: Kann ich mehr darüber lernen, ohne Entwickler zu werden? Ja. Lesen Sie die Dokumentation von Supabase; sie erklärt Backend-, Datenbank- und Auth-Konzepte gut, auch für Nicht-Entwickler.

Fazit

• Nicht-technische Gründer müssen 2026 nicht programmieren lernen, um echte Software zu launchen --- aber sie brauchen konzeptionelle Kompetenz zu Backend, Datenbank und Auth.
• Das Backend ist der Teil der App, den Nutzer nicht sehen. Die Datenbank ist, wo die Informationen der App leben. Auth ist, wie die App weiß, wer jemand ist und was er darf.
• Ihre Datenfelder zu typisieren (id uuid, name text usw.) statt sie vage zu beschreiben, transformiert die Qualität des KI-Builder-Outputs.
• Prompten Sie immer explizit für Row-Level Security. Ohne sie lecken Apps Daten.

Wählen Sie die SaaS-Idee, die Sie schon länger aufgeschoben haben. Öffnen Sie ein leeres Dokument. Listen Sie die Tabellen auf, die Sie brauchen, mit typisierten Feldern. Wählen Sie Magic-Link-Auth. Fügen Sie eine Zeile zu Row-Level Security hinzu. Dieses Dokument ist das Fundament für ein sauberes v1. Nächste Woche haben Sie ein funktionierendes SaaS gelauncht --- gebaut mit KI, aber informiert von den Konzepten, die KI-Builder dazu bringen, sauberen Output zu produzieren.