SaaS-MVP bauen: Konten, Abrechnung, eine Kernfunktion

Um ein SaaS-MVP zu bauen, wähle die eine Aufgabe, die dein Produkt für einen bestimmten Kunden erledigt, baue diese Aufgabe von Anfang bis Ende mit Anmeldung und einer Datenbank dahinter, ergänze eine einfache Zahlungsmöglichkeit, sobald du testen willst, ob Menschen zahlen, und bring es so früh wie möglich vor echte Nutzer, auch wenn es dir noch ein bisschen peinlich ist. Ein KI-App-Builder kann dich in Tagen von einer Beschreibung zu einem funktionierenden, gehosteten Produkt bringen. Am schwierigsten und wertvollsten ist es, zu entscheiden, was du weglässt.

Was ein MVP ausmacht und kein kleines SaaS

Ein MVP (Minimum Viable Product) soll eine Frage beantworten, meist „Werden diese Leute das nutzen, und werden sie dafür zahlen?“, und zwar mit möglichst wenig Bauaufwand. Alles darin sollte dieser Frage dienen. Siehe was ein MVP ist, falls dir der Begriff neu ist.

Daraus ergibt sich ein nützlicher Test für jede Funktion: Würde ein erster Kunde das Produkt ohne sie ablehnen? Wenn nicht, wartet sie.

Teams und Rollen verdienen eine besondere Erwähnung: Sie betreffen jede Tabelle und jede Berechtigungsprüfung. Wenn deine ersten Kunden Einzelpersonen oder sehr kleine Teams sind, beginne mit Einzelkonten und ergänze Teams, sobald jemand fragt, ob er eine Kollegin einladen kann.

Vor dem Bauen: ein Satz

"[Produkt] hilft [einem bestimmten Kunden], [eine bestimmte Aufgabe] zu erledigen, ohne [den heutigen Schmerz]."

Zum Beispiel: „Proposly hilft freiberuflichen Designern, aus einem Erstgespräch in zehn Minuten ein bepreistes Angebot zu machen, ohne bei einem leeren Dokument zu beginnen.“

Wenn du diesen Satz nicht formulieren kannst, verbringe eine Sitzung mit Planung, bevor du baust. Wie du eine App-Idee validierst behandelt das Gespräch mit potenziellen Kunden, den günstigsten Schritt im ganzen Prozess.

Was ein SaaS-MVP braucht

Konten und Datentrennung

Jede Information gehört einem Nutzer (oder später einem Team). Jede Abfrage muss auf dem Server nach dem angemeldeten Nutzer filtern. Machst du das falsch, hast du einen der schädlichsten Fehler, die eine Mehrnutzer-App haben kann: Nutzer A öffnet die Datensätze von Nutzer B, indem er eine ID in der URL ändert. Verlange die Datentrennung ausdrücklich und teste sie mit zwei Konten.

Login-Optionen: E-Mail und Passwort, gespeichert (gehasht) in deiner eigenen Datenbank, Magic Links per E-Mail oder ein gehosteter Auth-Anbieter. Jede Variante funktioniert; ein gehosteter Anbieter übernimmt Passwort-Zurücksetzungen und Sicherheitsdetails für dich, dafür kommt ein weiterer Dienst hinzu. Siehe wie du Login in deine App einbaust.

Abrechnung

Für Abos ist Stripe die übliche Wahl. Das Standardmuster:

1. Der Nutzer klickt auf Upgrade; dein Server erstellt eine Stripe-Checkout-Session im Abo-Modus.
2. Der Nutzer bezahlt auf der gehosteten Seite von Stripe.
3. Stripe sendet Webhooks, wenn das Abo beginnt, sich verlängert, fehlschlägt oder gekündigt wird. Deine App speichert den Status im Konto des Nutzers.
4. Deine App prüft diesen Status auf dem Server, bevor sie bezahlte Funktionen freigibt.
5. Das gehostete Kundenportal von Stripe lässt Nutzer Karten aktualisieren, Rechnungen einsehen und kündigen, sodass du keine eigene Abrechnungsseite bauen musst.

Die Standardpreise von Stripe bestehen aus einem prozentualen Anteil pro Transaktion plus einer festen Gebühr, ohne monatliche Grundgebühr (Stand September 2026). Stripe Billing, das Abos verwaltet, kommt auf dem Pay-as-you-go-Tarif mit einem kleinen Prozentsatz des Abrechnungsvolumens hinzu. Die Sätze variieren, prüfe deshalb die Preisseite von Stripe für dein Land. Lege die Preise vor dem Start fest; wie du ein SaaS-Produkt bepreist hilft dabei. Baue alles zuerst im Testmodus. Unser Leitfaden zu Zahlungen einbauen zeigt die Einrichtung.

Die Kernfunktion

Hier sollte deine Zeit hinfließen. Baue ihren vollständigen Ablauf: anlegen, auflisten, bearbeiten, löschen und was auch immer den „Moment des Nutzens“ ausmacht, etwa den Export, das erzeugte Ergebnis oder die versendete Nachricht. Gestalte den leeren Zustand hilfreich: Ein neuer Nutzer ohne Daten sollte genau wissen, was er als Erstes tun muss.

Die unverzichtbaren Grundlagen

• Transaktions-E-Mails (Willkommen, Passwort zurücksetzen, Belege) über einen Anbieter wie Resend oder Postmark
• Eine Datenschutzerklärung und Nutzungsbedingungen
• Eine Möglichkeit, das Konto zu löschen
• Grundlegende Analysen, damit du weißt, ob Menschen zurückkommen

Ein erster Prompt, der funktioniert

Baue ein SaaS-MVP namens Proposly für freiberufliche Designer. Landingpage: Überschrift, drei Vorteile, ein Preisbereich mit einem Tarif für 19 $/Monat und ein Button zur Anmeldung. Die App (nach dem Login): ein Dashboard mit den Angeboten des Nutzers; ein Formular „Neues Angebot“ mit Kundenname, Projektart, Aufzählung des Umfangs und Stundensatz; eine erzeugte Angebotsseite mit einer Umfangstabelle und einem Gesamtpreis, die der Nutzer bearbeiten und als PDF exportieren kann. Jeder Nutzer sieht nur seine eigenen Angebote – erzwinge das auf dem Server. Speichere alles in einer Datenbank. Verwende für jetzt einen einfachen Platzhalter-Login; echte Authentifizierung und Stripe-Abrechnung kommen danach. Klares, professionelles Design.

Der Prompt beschreibt den Kunden, den Ablauf und die Datengrenze und verschiebt Login und Abrechnung bewusst, damit das erste Ergebnis sich auf die Funktion konzentriert, auf die es ankommt.

Bauschritte

1. Kernfunktion mit Beispieldaten. Iteriere, bis sich die Hauptschleife richtig anfühlt.
2. Datenbank. Stelle sicher, dass Daten Neuladen und neue Sitzungen überstehen.
3. Echte Konten. Anmeldung, Login, Zurücksetzen. Teste dann die Datentrennung mit zwei Konten in zwei Browsern.
4. Landingpage. Erkläre den einen Satz. Platziere den Anmelde-Button oberhalb des Falzes.
5. Abrechnung. Stripe Checkout, Webhooks, eine Prüfung des Bezahlstatus auf dem Server und das Kundenportal. Teste eine erfolgreiche Zahlung, eine abgelehnte Karte und eine Kündigung.
6. E-Mails für Willkommen, Zurücksetzen und Belege.
7. Sicherheitsdurchgang. Unsere Sicherheitscheckliste für KI-gebaute Apps ist eine gute Liste, die du durchgehst.
8. Auf deiner eigenen Domain veröffentlichen und deine ersten zehn Nutzer persönlich einladen.

Häufige Fehler

• Für alle bauen. Ein Produkt für „kleine Unternehmen“ ist schwerer zu bauen und zu verkaufen als eines für „selbstständige Buchhalterinnen“.
• Admin-Panels vor Kunden. Eine Zeit lang kannst du die Datenbank direkt ansehen.
• Dem Browser beim Zugriff vertrauen. Einen Button zu verstecken hält keine Anfrage auf. Prüfe Tarif und Eigentümerschaft auf dem Server.
• Bezahlten Zugriff auf der Erfolgsseite freischalten statt über den Stripe-Webhook.
• Warten, bis es fertig ist. Die erste Version sollte sich ein bisschen peinlich anfühlen. Wie du eine App startest und erste Nutzer gewinnst bietet Ideen für den Schritt nach dem Bauen.

Messen, ob es funktioniert

Lege vor dem Start fest, was „funktioniert“ bedeutet, sonst wird jedes Ergebnis ermutigend aussehen. Bei den meisten SaaS-MVPs reichen drei Zahlen:

• Aktivierung: wie viele Neuanmeldungen die Kernschleife mindestens einmal abschließen – etwa das erste Angebot erstellen oder den ersten Bericht laufen lassen.
• Rückkehr: wie viele in der folgenden Woche zurückkommen und es erneut tun.
• Zahlung: wie viele der aktiven Nutzer bezahlen oder ja sagen, wenn du sie fragst.

Verfolge diese Werte mit einem einfachen Analysetool oder ein paar Abfragen auf deiner eigenen Datenbank und sprich mit Nutzern, die abspringen. Ihre Gründe sind mehr wert als jedes Dashboard.

Wann du nicht bauen solltest

Wenn das Produkt im Wesentlichen eine dünne Schicht über einem bestehenden Werkzeug ist – ein Formular, eine Tabelle, ein Newsletter –, teste die Idee zuerst mit diesem Werkzeug. Ein Typeform plus ein Stripe-Zahlungslink kann die Nachfrage prüfen, bevor du etwas baust. Baue das MVP, wenn der Wert im Ablauf selbst liegt und bestehende Werkzeuge ihn nicht liefern können.

Mit Mythex bauen

Auf Mythex beschreibst du das Produkt, und der Agent baut Landingpage und App gemeinsam in einer Live-Vorschau; eine eigene Postgres-Datenbank wird ergänzt, wenn du Daten speichern lassen willst. Der Docs-Anwendungsfall SaaS-MVP folgt derselben schlanken Reihenfolge wie dieser Leitfaden. Der Plan-Modus ist vor dem ersten Build nützlich, wenn du die Idee noch formst.

Beachte, was du selbst mitbringst: Der Login für die Nutzer deiner App verwendet einen Auth-Ansatz oder Anbieter deiner Wahl (Authentifizierung hinzufügen), und Abos laufen über dein eigenes Stripe-Konto mit Schlüsseln, die als Projekt-Secrets gespeichert werden. Mythex hat keine eingebaute SaaS-Abrechnung, keine Nutzungsmessung und kein Team-SSO für deine Kunden. Auf Pro kannst du eine eigene Domain verbinden und den Code exportieren oder mit GitHub synchronisieren, damit später ein Entwickler übernehmen kann. Für Start-Prompts schau dir die App-Vorlagen oder die SaaS-Dashboard-Vorlage an.

Fragen