Welche Funktionen braucht eine SaaS-Website jenseits der Produktseite? Wie lassen sich Benutzer-Login, Abonnementzahlungen und Admin-Backend umsetzen?

Eine SaaS-Website, die nur klar erklärt, „welches Problem wir lösen“, kann höchstens Anfragen gewinnen, aber keine registrierten Nutzer. Was SaaS tatsächlich tragfähig macht, ist das Zusammenspiel von vier Ebenen: Die Marketingebene sorgt dafür, dass Menschen es verstehen und ausprobieren wollen; die Kontoebene bestätigt „wer du bist“; die Abrechnungsebene bestätigt „wie viel du bezahlt hast und was du dafür bekommst“; die Anwendungs- und Verwaltungsebene erfüllt das Versprechen im täglichen Gebrauch. Fehlt eine Ebene, verkommt die Website zum Prospekt.

Für Gründer und kleine Softwareteams empfiehlt sich diese Reihenfolge: zuerst das Kontosystem ergänzen, dann die Abonnement-Abrechnung, zuletzt Backend und Berechtigungen. Die drei Bereiche hängen stark voneinander ab: Ohne Konto gibt es keinen Zuordnungsträger, ohne Abrechnung keine unterscheidbaren Rechte, ohne Backend keine Möglichkeit für manuelle Eingriffe.

Worin unterscheiden sich SaaS-Website und tatsächliche Produktoberfläche?

Nutzer, Ziele und technische Anforderungen dieser beiden Seitentypen sind völlig unterschiedlich. Sie zusammenzulegen ist für viele Projekte der erste Punkt, an dem sie stecken bleiben.

Ein häufiger Fehler besteht darin, auch den Workspace für Suchmaschinen crawlbar zu machen oder die Preisseite hinter einer Login-Schranke zu verstecken. Ersteres legt die Produktstruktur offen und verwässert das Seitenthema; Letzteres führt dazu, dass potenzielle Kunden vor der Entscheidung keine Preise sehen und direkt abspringen. Die richtige Vorgehensweise ist, bereits auf Routing-Ebene zu trennen: Öffentliche Routen liefern indexierbare Inhalte aus, Anwendungsrouten erzwingen Authentifizierung und verbieten die Indexierung.

Welche Module braucht eine SaaS-Website, die tatsächlich läuft?

Funktionen nach Ebenen aufzuteilen erleichtert die Planung mehr als die Aufteilung nach Seiten.

Wenn die Zeit nur für die Hälfte reicht, sollten zuerst Kontoebene, Abrechnungsebene und ein minimal nutzbarer Workspace umgesetzt werden; die Verwaltungsebene kommt zuletzt. Das Admin-Backend kann zunächst mit der einfachsten Tabellenlösung realisiert werden, aber es muss vorhanden sein – sonst bleiben bei Problemen mit den ersten zahlenden Nutzern nur manuelle Datenbankänderungen.

Wie setzt man Benutzerregistrierung, E-Mail-Verifizierung und Login um?

Der Umsetzungspfad lässt sich in fünf Schritten zusammenfassen:

1. Login-Methode wählen: E-Mail und Passwort als Hauptmethode, ergänzt durch OAuth wie Google oder GitHub als schnellen Einstieg; das senkt die Registrierungshürde deutlich.
2. Konto anlegen und Verifizierungs-E-Mail senden: Nach erfolgreicher Registrierung sofort ein einmaliges Verifizierungs-Token erzeugen, an das Konto binden und ein Ablaufdatum setzen; nicht verifizierte Konten werden als „ausstehend“ markiert und erhalten keinerlei kostenpflichtige Rechte.
3. Verifizierung und Ratenbegrenzung beim erneuten Senden: Der Verifizierungslink darf nur einmal verwendet werden; das erneute Senden an dieselbe E-Mail-Adresse muss frequenzbegrenzt werden, sonst wird das System zum Werkzeug für Mail-Bombing.
4. Sitzung aufrechterhalten: Serverseitige Sessions oder signierte Tokens verwenden, kombiniert mit HttpOnly- und Secure-Cookies; das Frontend sollte keine dauerhaft von Skripten auslesbaren Zugangsdaten speichern.
5. Passwort zurücksetzen und Verknüpfungen lösen: „Passwort vergessen“ über einen einmaligen Link zurücksetzen; bei Drittanbieter-Logins muss Verknüpfen und Entkoppeln möglich sein, damit Nutzer nach einem E-Mail-Wechsel nicht dauerhaft ihr Konto verlieren.

Bei Sicherheitsdetails sollten Verschlüsselung und Hashing nicht selbst entwickelt werden; stattdessen sind Passwort-Hashing und Sitzungsmechanismen etablierter Frameworks zu verwenden. E-Mail-Verifizierung, Google-/GitHub-Login und ein grundlegendes Kontosystem gehören zur allgemeinen Infrastruktur. Die Full-Stack-Generierungsfähigkeiten von We0 decken solche Funktionen bereits ab (We0 Full-Stack-Codegenerierung); Teams können ihre Energie auf Geschäftsfelder und Berechtigungsregeln konzentrieren.

Wie unterscheidet man kostenlose und zahlende Nutzer?

Der am leichtesten übersehene Punkt: Die Rechteprüfung muss serverseitig erfolgen; das Frontend dient nur der Darstellung. Das Ausblenden von Buttons im Frontend ist keine Einschränkung – wird die API direkt aufgerufen, wird sie trotzdem ausgeführt.

Empfohlenes Modell: drei Tabellen plus eine serverseitige Funktion: Die Tariftabelle definiert die Rechte-Merkmale jedes Plans; die Abonnementtabelle speichert den aktuellen Status des Kontos, den Zyklus und die externe Abonnement-ID; die Rechtetabelle speichert das kontobezogene Kontingent.

canUse(user, feature):
    if user.status != "active": return false        # nicht verifiziert oder gesperrt
    plan = plans[user.plan_id]
    if not plan.features.contains(feature): return false
    if plan.quota > 0 and user.used >= plan.quota: return false
    return true

Der Unterschied zwischen kostenlos und kostenpflichtig liegt typischerweise an drei Stellen: Funktionsschalter (erweiterte Berichte, Mehrbenutzer-Zusammenarbeit), Mengenkontingente (Anzahl Projekte, Mitglieder, Generierungen) und Datenaufbewahrungsdauer. Die Staffelung über Kontingente ist sanfter als über „Deaktivierung“ – kostenlose Nutzer müssen echten Nutzen erfahren, bevor sie aktiv upgraden.

Wie bindet man Stripe-Abonnementzahlungen ein?

Der Kern der Abonnement-Integration ist nicht der Button, sondern die Frage „wer bestimmt“. Es gibt nur eine Regel: Der Abonnementstatus der Zahlungsplattform ist die einzige Wahrheitsquelle; die Felder in der eigenen Datenbank sind nur Kopien.

1. Preisobjekte anlegen: Je ein Preis für Monats- und Jahreszahlung anlegen, die Preis-IDs in Umgebungsvariablen schreiben und Beträge nicht im Frontend hartcodieren.
2. Checkout starten: Serverseitig eine Checkout-Session erstellen, die Konto-ID in die metadata schreiben und den Nutzer zum Abschluss der Zahlung von der Website weiterleiten.
3. Callbacks empfangen: Einen Webhook-Endpunkt konfigurieren; Ereignisse wie Abonnement erstellt, Verlängerung erfolgreich, Zahlung fehlgeschlagen und Abonnement gekündigt müssen verarbeitet werden. Der Callback ist der einzige Auslöser für die Freischaltung von Rechten.
4. Callbacks wiederholbar machen: Dasselbe Ereignis kann mehrfach zugestellt werden; die Verarbeitungslogik muss idempotent sein und nach Ereignis-ID oder Abonnement-ID deduplizieren; die Antwort muss schnell zurückkehren, zeitaufwendige Aktionen asynchron ausgeführt werden.
5. Status-Mapping: Externe Abonnementstatus auf interne Status abbilden; der Geschäftscode kennt nur interne Status und liest keine externen Felder direkt.
6. Abrechnungszugang bereitstellen: Weiterleitung zum Kundenportal der Zahlungsplattform für Rechnungen und Karten spart im Vergleich zu einer selbst entwickelten Abrechnungsseite viel Wartungsaufwand.

Wie schaltet man Funktionen nach erfolgreicher Zahlung frei?

Dieser Abschnitt ist am fehleranfälligsten: Der Nutzer sieht auf der Zahlungserfolgsseite „Willkommen“, aber die Rechte sind noch nicht in der Datenbank gespeichert; beim Betreten erscheint ein leerer Workspace oder erneut die Zahlungsaufforderung.

Die richtige Vorgehensweise: „Zahlung erfolgreich“ und „Rechte aktiv“ als zwei unabhängige Ereignisse behandeln. Erst wenn der Callback eintrifft und erfolgreich validiert wurde, werden Abonnement geschrieben, Rechte aktualisiert und Willkommens-E-Mail versendet; die Zahlungserfolgsseite pollt lediglich die eigene API, um auf die Verfügbarkeit der Rechte zu warten, und zeigt bei Timeout „Zahlung wird verarbeitet, Benachrichtigung per E-Mail folgt“ an, statt direkt freizugeben.

Auch Downgrades müssen gestaltet werden. Ablauf, Zahlungsverzug und Rückerstattung sollten einen einheitlichen Herabstufungsprozess durchlaufen: zunächst Lesezugriff für eine gewisse Zeit beibehalten, dann schrittweise Schreib- und Exportfunktionen schließen. Alle Rechte abrupt zu entziehen verärgert Nutzer; alle Rechte unbegrenzt zu behalten bedeutet, das Produkt kostenlos zu verschenken.

Wo verwalten Nutzer Konto und Tarif?

Eine vollständige Kontoseite reduziert viele Support-Tickets. Mindestens enthalten: Profil und Passwort, E-Mail-Änderung (mit erneuter Verifizierung), aktueller Tarif und Verlängerungsdatum, Nutzung und Kontingentrest, Rechnungshistorie und Download, Upgrade-/Downgrade-/Kündigungszugang, Abmeldung von allen Geräten und Kontolöschung.

Tarifänderungen müssen nach Richtung unterschieden werden: Upgrades werden sofort wirksam und anteilig berechnet; Downgrades werden auf den nächsten Zyklus verschoben, um Abrechnungsdurcheinander durch häufiges Wechseln zu vermeiden. Bei der Kündigung sind keine mehrstufigen Rückhaltedialoge nötig; eine klare Bestätigung plus der Satz „Rechte bleiben bis zum X. gespeichert“ ist deutlich wirksamer als zehn Dialogebenen.

Was sollte das Admin-Backend verwalten?

Das Backend ist kein „Dashboard für den Chef“, sondern ein Werkzeug zur Ausnahmebehandlung.

Der häufigste Fehler im Backend ist, das Admin-Konto zum Generalschlüssel zu machen. Empfohlen sind mindestens drei Stufen: schreibgeschützter Betrieb, Bestellungen und Nutzer bearbeiten, Abrechnung und Berechtigungen ändern. Alle sensiblen Aktionen werden in einem Audit-Log protokolliert, damit bei Problemen nachvollziehbar ist, wer wann was geändert hat.

Sollten Website und Backend in ein Projekt oder in zwei Systeme?

Frühe Teams sollten fast immer ein einzelnes Projekt wählen: gemeinsame Domain und Session; Nutzer registrieren sich auf der Startseite und gelangen direkt in den Workspace, ohne Single Sign-on zwischen mehreren Systemen; Inhalte, SEO und Produktupdates liegen in derselben Routing- und Deployment-Struktur, was den Betriebsaufwand minimiert. Auch öffentliche SaaS-Beispiele für Authentifizierung und Kontoverwaltung verwenden diese integrierte Form; Authentifizierung, Rollenberechtigungen, Abonnements, Domain und Deployment werden in derselben Anwendung umgesetzt (SaaS Auth Dashboard-Beispiel).

Erst wenn das Team klar aufgeteilt ist und der Traffic so groß wird, dass eine unabhängige Skalierung nötig ist, sollte man in Website, Frontend-Anwendung und Backend-Dienste aufteilen. Der Preis dafür ist die Pflege von Cross-Domain-Sessions, einheitlicher Authentifizierung und Inhaltssynchronisierung. Drei Kriterien helfen bei der Entscheidung: Wird die Website mehrmals pro Woche aktualisiert, während die Anwendung nur alle halbe Jahre eine Version erhält? Gibt es bereits mehrere Personen, die getrennt für Marketing und Produktentwicklung zuständig sind? Hat die Anwendung eigene Anforderungen an Skalierung und Datenbankisolierung? Erst wenn alle drei zutreffen, aufteilen; sonst zuerst zusammenführen.

Auch innerhalb eines einzelnen Projekts müssen die Grenzen klar sein: Marketing-Routen führen keine Authentifizierung durch, müssen aber indexierbar sein; Anwendungsrouten erzwingen Authentifizierung und verbieten Indexierung; die API-Ebene prüft Rechte einheitlich; Backend-Routen erhalten zusätzliche Rollenprüfungen. We0 legt Seitenstruktur, Authentifizierung, Abonnements und Credits, CMS und Backend, Mehrsprachigkeit, SEO und Deployment in dieselbe Generierungskette (We0 Full-Stack-Codegenerierung) und eignet sich für Teams, die Website und Produkteinstieg in einem Projekt abbilden möchten; konkrete Geschäftsregeln und Berechtigungsgrenzen müssen dennoch nach Produktanforderungen definiert werden.

Ein vollständiger Durchlauf mit einem Projektmanagement-SaaS

Angenommen, wir bauen ein Projektmanagement-SaaS für kleine Teams: Die kostenlose Version umfasst 3 Projekte, der Professional-Tarif unbegrenzte Projekte und Mitglieder-Zusammenarbeit.

1. Startseite: Klar sagen, „wer es in welchem Szenario nutzt“, einen kostenlosen Registrierungszugang anbieten, keine Kreditkarte verlangen.
2. Preisseite: Drei Tarife nebeneinander, Unterschiede zwischen Monats- und Jahreszahlung ausweisen, Kontingente und Einschränkungen nennen.
3. Registrierung und Verifizierung: Nach der E-Mail-Registrierung sofort die Verifizierungs-E-Mail erhalten; erst nach Abschluss der Verifizierung dürfen Projekte erstellt werden.
4. Abonnementzahlung: Im Workspace auf Upgrade klicken, zur gehosteten Checkout-Seite weiterleiten, Monats- oder Jahreszahlung wählen.
5. Rechtefreischaltung: Der Callback schreibt den Abonnementstatus; nach dem Aktualisieren des Workspace wird das Projektlimit aufgehoben und der aktuelle Tarif sowie das Verlängerungsdatum angezeigt.
6. Nutzer-Workspace: Nur die eigenen Projekte des Kontos anzeigen; Mitgliedereinladungen werden nach Sitzplätzen geprüft.
7. Admin-Backend: Der Support kann Nutzer suchen, Abonnements einsehen und für überfällige Nutzer manuell um einen Tag verlängern.

In dieser Kette kostet nicht die Seite die meiste Zeit, sondern die Statuskonsistenz in Schritt 5 und die Ausnahmebehandlung in Schritt 7. Viele Teams verwenden 80 % der Zeit auf die visuelle Gestaltung der Startseite und bearbeiten nach dem Launch Zahlungsverzug und Rückerstattungen manuell.

Checkliste vor dem Launch

• Sind Konten mit nicht verifizierter E-Mail von kostenpflichtigen Rechten ausgeschlossen?
• Wird jede Rechteprüfung serverseitig ausgeführt?
• Sind Zahlungs-Callbacks idempotent und wird ausschließlich der Plattformstatus berücksichtigt?
• Wartet die Zahlungserfolgsseite darauf, dass die Rechte in der Datenbank gespeichert sind, statt direkt freizugeben?
• Gibt es für Zahlungsverzug, Kündigung und Rückerstattung jeweils einen passenden Herabstufungspfad?
• Sind Anwendungsrouten für die Indexierung gesperrt und öffentliche Seiten indexierbar?
• Gibt es für Admin-Aktionen ein Audit-Log und minimale Berechtigungen?
• Stammen Website-Inhalte und Hilfedokumentation aus derselben Quelle, um langfristige Abweichungen zu vermeiden?

FAQ

Kann eine SaaS-Website nur aus einer Produktseite bestehen?
Als vorübergehende Landingpage ist das möglich, aber sie kann nur Leads gewinnen und weder Registrierung, Testphase noch Zahlung tragen. Wenn Nutzer auf „Kostenlos starten“ klicken und nirgendwohin gelangen, ist der Traffic verschwendet.

Kann man ohne Programmierkenntnisse ein SaaS bauen?
Allgemeine Infrastruktur wie Konto, Abonnement, Backend und Deployment lässt sich mit ausgereiften Plattformen oder KI-Generierungsfähigkeiten schnell aufbauen, aber Abrechnungsregeln, Berechtigungsgrenzen und Datenmodell müssen weiterhin von Menschen entworfen und validiert werden. Werkzeuge reduzieren wiederholte Engineering-Arbeit, ersetzen aber keine Produktentscheidungen.

Muss man für Abonnementzahlungen Stripe verwenden?
Nein, aber die Auswahl hängt vom Zielmarkt und Abrechnungszyklus ab. Stripe bietet verhältnismäßig vollständige Abonnements, Rechnungen und Kundenportal; für Nutzer im Inland sind zusätzlich lokale Zahlungsmethoden zu berücksichtigen. Unabhängig vom Anbieter gilt die Regel „externer Status als einzige Wahrheitsquelle“.

Wie unterscheidet man kostenlose und zahlende Nutzer am einfachsten?
Tariftabelle, Rechtetabelle und eine serverseitige Prüffunktion. Bedingte Prüfungen sollten nicht über viele Seiten verstreut werden, sonst müssen bei einem neuen Tarif Dutzende Stellen geändert werden.

Sollten Website und Backend im selben Projekt liegen?
In der frühen Phase im selben Projekt mit gemeinsamer Domain und Session, das minimiert den Betriebsaufwand; erst wenn Team und Traffic unabhängig iterieren müssen, aufteilen.

Was tun, wenn die Zahlung erfolgreich war, aber Funktionen nicht freigeschaltet sind?
Zuerst prüfen, ob der Callback angekommen ist, ob die Signatur validiert wurde und ob die Idempotenz-Deduplizierung fälschlich gegriffen hat; dann prüfen, ob die Rechte geschrieben wurden. Auf Nutzerseite müssen klare „In Bearbeitung“-Rückmeldungen und ein manueller Support-Kanal bereitstehen, statt Nutzer zu erneuter Zahlung zu verleiten.

Verwandte Werkzeuge

• Stripe-Dokumentation: ursprüngliche Erläuterung zu Abonnements, Checkout und Callback-Mechanismen
• Komponentenbibliotheken wie React + Shadcn UI: schneller Aufbau von Workspace-Tabellen, Diagrammen und Paginierungsinteraktionen (Implementierungsreferenz)
• Design-zu-Code-Werkzeuge: Backend-Oberflächendesigns direkt in lauffähige Seiten umwandeln
• We0.ai: Authentifizierung, Zahlung, CMS-Backend und Deployment in einem Projekt kombinieren

Verwandte Links

• We0 Full-Stack-Codegenerierung
• SaaS Auth Dashboard: Beispiel für Authentifizierung und Kontoverwaltung
• Build a SaaS Admin Dashboard with React, Shadcn UI & TypeScript

Zusammenfassung

Eine SaaS-Website, die nur eine Produktseite hat, löst „Vertrauen schaffen“; Login, Abonnementzahlung und Backend-Verwaltung lösen „tatsächlich nutzen und dauerhaft zahlen“. Empfohlene Reihenfolge: Kontosystem, Abonnement-Abrechnung, minimal nutzbarer Workspace, Admin-Backend. Technisch gibt es drei harte Vorgaben: Rechteprüfung serverseitig, Status der Zahlungsplattform als einzige Wahrheitsquelle, Zahlungserfolg und Rechteaktivierung getrennt behandeln. Website und Backend können früh in einem Projekt mit gemeinsamer Domain und Session liegen; erst wenn Team und Traffic unabhängig iterieren müssen, aufteilen.