SaaS-MVP entwickeln: Umfang, Mandantenfähigkeit, Abrechnung und der Stack, mit dem wir starten

Ein SaaS-MVP ist die kleinste Version eines Abo-Produkts, für die sich ein echter Kunde registrieren, mit der er die Hauptaufgabe erledigen und für die er bezahlen kann. Der Umfang ist schwerer festzulegen als bei einer einmaligen App, weil die Teile, die niemand sieht (Konten, Teams, Rollen, Abrechnung, Mandantentrennung), vom ersten Tag an funktionieren müssen. Dieser Leitfaden beschreibt den Prozess, nach dem wir SaaS-Produkte entwickeln: wie Sie den Umfang des MVP festlegen, wie Sie ein Mandantenmodell wählen, wie Sie die Abrechnung aufsetzen, mit welchem Tech-Stack wir starten und welche Checkliste vor dem Launch gilt. Dazu kommt ein kurzes Node.js-Beispiel für die Mandantentrennung.

Was ein SaaS-MVP enthalten muss

Ein normales MVP prüft eine Frage: Wollen die Leute das? Ein SaaS-MVP prüft zusätzlich eine zweite: Zahlt ein Unternehmen jeden Monat dafür? Diese zweite Frage bringt Anforderungen mit, die ein Prototyp auslassen kann.

• Konten, die zu einer Organisation gehören. Geschäftskunden registrieren sich als Unternehmen, laden Kollegen ein und erwarten Rollen.
• Mandantentrennung. Ein Kunde darf nie die Daten eines anderen Kunden sehen. Das ist eine Architekturentscheidung, und sie nachträglich einzubauen ist teuer.
• Abrechnung. Tarife, Testphasen, Upgrades, fehlgeschlagene Zahlungen und Kündigungen. Jeder dieser Fälle ändert, was der Nutzer im Produkt tun kann.
• Eine Admin-Ansicht für Sie. Sie müssen sehen, wer sich registriert hat, welchen Tarif er nutzt und wo er hängen geblieben ist.
• Die eine Kernaufgabe. Die Funktion, für die der Kunde bezahlt, und zwar gut umgesetzt.

Alles andere kann warten. Die folgende Tabelle zeigt die Aufteilung, mit der wir den Umfang festlegen.

Den Umfang festlegen: eine Aufgabe, ein Käufer, ein bezahlter Tarif

Die meisten SaaS-MVPs, die sich in die Länge ziehen, haben mit einer Feature-Liste begonnen. Beginnen Sie mit einem Satz.

1. Benennen Sie den Käufer. „Operations-Manager in Logistikunternehmen mit 20 bis 200 Mitarbeitenden“ ist ein Käufer. „Unternehmen“ ist keiner.
2. Benennen Sie die Aufgabe. Schreiben Sie auf, was der Käufer heute ohne Ihr Produkt tut und welchen einen Schritt Sie ersetzen.
3. Definieren Sie den bezahlten Moment. Legen Sie fest, was ein Kunde im bezahlten Tarif bekommt und in der Testphase nicht. Wenn Sie das nicht sagen können, ist der Tarif noch nicht fertig.
4. Schreiben Sie den Pfad der ersten Sitzung auf. Listen Sie jeden Bildschirm von der Registrierung bis zum ersten nützlichen Ergebnis auf. Was nicht auf diesem Pfad liegt, kann gestrichen werden.
5. Legen Sie den Launch-Test fest. Zum Beispiel: Fünf Unternehmen erledigen die Kernaufgabe in zwei Wochen zweimal, und drei davon hinterlegen eine Karte.
6. Halten Sie fest, was nicht dazugehört. Bewahren Sie die Liste auf. Nach dem Launch wird sie zu Ihrer Roadmap.

Hängt die Kernaufgabe von einem Sprachmodell ab, legen Sie den Umfang des KI-Teils getrennt fest und testen Sie ihn zuerst. Das behandelt unser Leitfaden zur Entwicklung eines KI-MVP.

Das Mandantenmodell wählen, bevor Sie Code schreiben

Mandantenfähigkeit (Multi-Tenancy) bedeutet, dass sich viele Kunden ein laufendes Produkt teilen. Die AWS SaaS Lens beschreibt drei Modelle, und die Namen sind weit verbreitet.

Wir starten die meisten MVPs mit dem Pool-Modell und machen die Trennung zu einer Eigenschaft der Datenbank, nicht jeder einzelnen Abfrage. Die Row-Level Security von PostgreSQL leistet das: Sie aktivieren sie pro Tabelle und schreiben eine Richtlinie, und die Datenbank verweigert Zeilen anderer Mandanten, auch wenn der Anwendungscode einen Filter vergisst.

```sql
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON projects
USING (tenant_id = current_setting('app.tenant_id')::uuid);
```

Die Anwendung setzt dann für jede Anfrage den Mandanten innerhalb einer Transaktion. Hier ist eine kleine Hilfsfunktion mit node-postgres:

```js
import pg from "pg";

const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });

// Führt work in einer Transaktion aus, in der jede Abfrage auf einen Mandanten begrenzt ist.
export async function withTenant(tenantId, work) {
const client = await pool.connect();
try {
await client.query("BEGIN");
// Das dritte Argument (true) lässt die Einstellung nur für diese Transaktion gelten.
await client.query("SELECT set_config('app.tenant_id', $1, true)", [tenantId]);
const result = await work(client);
await client.query("COMMIT");
return result;
} catch (err) {
await client.query("ROLLBACK");
throw err;
} finally {
client.release();
}
}

// Verwendung: Die Abfrage hat keinen Mandantenfilter und liefert trotzdem nur die Zeilen dieses Mandanten.
const projects = await withTenant(session.tenantId, (db) =>
db.query("SELECT id, name FROM projects ORDER BY created_at DESC")
);
```

Zwei Details sind wichtig. Die PostgreSQL-Dokumentation weist darauf hin, dass Tabelleneigentümer die Row-Level Security umgehen, sofern Sie nicht FORCE ROW LEVEL SECURITY verwenden, und dass Superuser sie immer umgehen. Die Anwendung sollte sich deshalb mit einer Rolle verbinden, die weder das eine noch das andere ist. Außerdem muss die Mandanten-ID aus der geprüften Sitzung auf dem Server stammen, nie aus einem Wert, den der Browser sendet.

Fehlerhafte Zugriffskontrolle (Broken Access Control) ist der erste Punkt der OWASP Top 10 (2021). In einem SaaS-Produkt ist ein Datenleck zwischen Mandanten die schädlichste Form davon. Deshalb behandeln wir die Trennung als Teil des MVP und schreiben automatisierte Tests, die sich als Mandant A anmelden und versuchen, die Datensätze von Mandant B zu lesen.

Abrechnung: Der Zahlungsanbieter ist die maßgebliche Quelle

Bei der Abrechnung verlieren SaaS-MVPs am häufigsten Zeit. Das Muster, das sich bewährt, ist einfach: Der Zahlungsanbieter führt den Status des Abonnements, und Ihr Produkt hält eine Kopie, die es über Webhooks aktualisiert.

• Nutzen Sie gehostete Seiten. Stripe Checkout nimmt die Zahlung entgegen, und im Kundenportal können Kunden Karten aktualisieren, Tarife wechseln und kündigen. Diese Bildschirme bauen Sie nicht selbst.
• Synchronisieren Sie über Webhooks. Der Abonnement-Leitfaden von Stripe nennt die Ereignisse, die Sie verarbeiten müssen, darunter checkout.session.completed, customer.subscription.updated, customer.subscription.deleted, invoice.paid und invoice.payment_failed.
• Prüfen und deduplizieren Sie. Prüfen Sie die Signatur jedes Webhooks und speichern Sie die IDs verarbeiteter Ereignisse, denn Anbieter können dasselbe Ereignis mehrfach zustellen.
• Steuern Sie Funktionen von einer Stelle aus. Halten Sie eine einzige Funktion vor, die aus gespeichertem Tarif und Status die Frage „Was darf diese Organisation?“ beantwortet. Verteilen Sie Tarifprüfungen nicht über den Code.
• Legen Sie den Ablauf bei fehlgeschlagener Zahlung fest. Entscheiden Sie, was passiert, wenn eine Karte abgelehnt wird: wie lange der Zugang bestehen bleibt und was der Nutzer sieht.

Hängen Sie das Abonnement an die Organisation, nicht an die Person, die die Karte eingegeben hat. Menschen verlassen Unternehmen, das Konto sollte nicht mit ihnen gehen.

Der SaaS-Tech-Stack, mit dem wir starten

Ein unspektakulärer Standard sorgt dafür, dass das Budget in die Kernaufgabe fließt. Das ist unser Ausgangspunkt für ein webbasiertes SaaS-MVP in JavaScript und TypeScript.

Eine mobile App ist meist ein späterer Schritt. Arbeitet der Käufer am Schreibtisch, liefern Sie zuerst das Webprodukt aus und ergänzen mobile Apps, sobald die Kernaufgabe bewiesen ist.

Der Entwicklungsprozess, Phase für Phase

Wir veröffentlichen keine Wochenangaben, weil dieselbe Phase von Produkt zu Produkt stark variiert. Entscheidend ist, was jede Phase liefern muss, bevor die nächste beginnt.

Was es verlängert: Integrationen mit anderen Systemen, Datenimporte aus dem alten Tool eines Kunden, mehr als zwei oder drei Rollen und Compliance-Anforderungen wie SSO oder Vorgaben zum Speicherort der Daten. Was es verkürzt: ein Käufer, ein Workflow und ein Entscheider, der Fragen schnell beantwortet.

Launch-Checkliste

1. Die Mandantentrennung wird in der Datenbank erzwungen, und automatisierte Tests versuchen, Mandantengrenzen zu überschreiten.
2. Rollen werden bei jeder Aktion auf dem Server geprüft, nicht nur in der Oberfläche ausgeblendet.
3. Passwörter verwaltet der Auth-Anbieter, Sitzungen laufen ab und lassen sich widerrufen.
4. Webhook-Signaturen werden geprüft, und Ereignisse werden genau einmal verarbeitet.
5. Eine fehlgeschlagene Zahlung, eine Kündigung und ein Tarifwechsel wurden jeweils durchgängig getestet.
6. Backups laufen automatisch, und eine Wiederherstellung wurde einmal getestet.
7. Fehler und langsame Anfragen erreichen eine Person, mit Angabe von Mandant und Nutzer.
8. E-Mails zu Registrierung, Einladung, Passwort-Reset und Belegen werden von Ihrer eigenen Domain zugestellt.
9. Datenschutzerklärung, Nutzungsbedingungen und ein Auftragsverarbeitungsvertrag liegen vor, und Sie wissen, wo Kundendaten gespeichert sind.
10. Sie können die Daten eines Kunden auf Anfrage exportieren oder löschen.
11. Es gibt eine Staging-Umgebung, und Deployments lassen sich zurückrollen.
12. Die Produktanalyse erfasst den Pfad der ersten Sitzung, sodass Sie sehen, wo neue Nutzer aufhören.

Häufige Fehler

• Zuerst für den zweiten Kunden bauen. Eigene Rollen, White-Labeling und Reporting entstehen, bevor ein einziger Kunde bezahlt hat.
• Mandantenfähigkeit später nachrüsten. Bei einem Produkt, das für einen Kunden gebaut und dann „mandantenfähig gemacht“ wurde, muss jede Tabelle und jede Abfrage neu geprüft werden.
• Eigene Abrechnungslogik schreiben. Anteilige Berechnung, Steuern und Wiederholungsversuche sind gelöste Probleme. Nutzen Sie die Lösung des Anbieters.
• Keine Admin-Ansicht. Das Team führt am Ende SQL von Hand aus, um Supportfragen zu beantworten.
• Den Stack für eine Größe wählen, die Sie nicht haben. Microservices und mehrere Datenbanken bremsen ein MVP und helfen ihm selten.

Was wir gebaut haben

Zwei Produkte, die wir ausgeliefert haben, zeigen das Muster. TMS ist unser eigenes mandantenfähiges SaaS-MVP für Teammanagement, mit Kanban-Boards, Sprints, Check-ins, HR und Gehaltsabrechnung. Cheggl ist ein deutsches Video-Branchenverzeichnis mit Unternehmens-Dashboard, Admin-Konsole und KI-Suche. Beide haben mit einer eng gefassten Kernaufgabe begonnen und sind von dort aus gewachsen.

Brauchen Sie Unterstützung bei Ihrem SaaS-MVP?

Wir planen und entwickeln SaaS-MVPs in TypeScript, mit Mandantenfähigkeit und Abrechnung ab dem ersten Release. Nennen Sie uns Käufer und Aufgabe auf unserer Seite zur SaaS-Entwicklung, oder lesen Sie, wie wir bei der MVP-Entwicklung vorgehen. Wenn Sie bereits ein Produkt haben und KI-Funktionen ergänzen möchten, lesen Sie unseren Leitfaden zur Integration von KI in ein SaaS-Produkt.

Quellen

• AWS Well-Architected SaaS Lens
• AWS SaaS Lens: Silo, pool and bridge models
• PostgreSQL: Row security policies
• node-postgres: Transactions
• Stripe: How subscriptions work
• Stripe: Using webhooks with subscriptions
• Stripe: Receive events in your webhook endpoint
• OWASP Top 10 (2021): Broken Access Control
• Next.js: App Router documentation