Wie ich ein SaaS bauen würde - Mandanten, Abrechnung und was es zum Produkt macht

Ein MVP beantwortet: wird jemand diese Aufgabe zu Ende bringen? Ein SaaS beantwortet: werden viele Firmen weiterzahlen, damit wir eine Codebasis für alle betreiben? Die zweite Frage ist nicht „Stripe und Login dazu“. Es ist Mandantenfähigkeit, Abrechnung, Einstieg und ein Weg, einem Fremden um 2 Uhr zu helfen, ohne per SSH in deren Daten zu gehen.

Wie ich den Stack für ein MVP wähle, habe ich schon geschrieben. Das ist die nächste Schicht: wenn die Geschäftsform Software-as-a-Service ist, was ich wirklich bauen würde, in welcher Reihenfolge, und was ich im ersten Monat nicht von Linear oder Salesforce kopieren würde.

1. Zuerst: ist das überhaupt SaaS?

Viele „SaaS-Ideen“ sind ein Custom-System für einen Kunden mit monatlicher Rechnung. Das kann ein gutes Geschäft sein. Es ist kein SaaS. SaaS heißt: ein Produkt, viele Mandanten, Self-Serve oder leichter Vertrieb, und die Kosten für die nächste Firma liegen nahe null - nicht noch ein Projekt.

• SaaS: viele Organisationen, dieselben Funktionen, Abrechnung im Produkt, die Verfügbarkeit liegt bei Ihnen.
• Custom: ein Käufer, einzigartige Abläufe, Sie rechnen Änderungswünsche ab. Tun Sie nicht so, als würde der zweite Kunde „einfach einloggen“.
• Wenn die ersten drei Kunden jeweils einen Fork brauchen, hören Sie auf, es SaaS zu nennen. Verkaufen Sie Projekte, bis die Überlappung offensichtlich ist - dann lösen Sie das Produkt heraus.

2. Die Einheit des Produkts ist der Workspace, nicht der Nutzer

Ich würde die Domain um eine Organisation bauen (Workspace, Tenant, Account - ein Wort wählen und behalten). Nutzer gehören zu Organisationen. Daten gehören zu Organisationen. Rechnungen gehören zu Organisationen. Wenn Sie mit „User hat Projects“ starten, schrauben Sie sechs Monate Teams, Einladungen und „wer zahlt“ drauf.

• Die Organisation hat einen Plan, eine Billing-E-Mail und einen Status: trial, active, past_due, canceled.
• Mitgliedschaft ist eine Zeile: User + Org + Rolle (owner, admin, member reicht am Anfang).
• Jede Geschäftstabelle hat org_id. Abfragen ohne org_id sind Bugs, keine Abkürzungen.
• Einladungen statt „User für die anlegen“. E-Mail rein, akzeptieren, im richtigen Workspace landen.

3. Mandantenfähigkeit: gemeinsame Datenbank, strikte Isolation

Für ein erstes SaaS würde ich kein Postgres pro Kunde aufmachen. Eine Datenbank, org_id auf jeder Zeile, und Schutz in der Tiefe, damit ein vergessenes WHERE kein Leak wird. Database-per-Tenant ist für regulierte Isolation oder laute Nachbarn, die Sie schon gemessen haben - nicht für Mandant Nummer vier.

• Row-Level Security oder ein Query-Helfer, der org_id immer aus der Session zieht - nicht aus dem Client-Body.
• IDs, die man nicht raten kann (UUIDs). Sequenzielle /org/12/invoices/4 sind eine Einladung.
• Dateispeicher mit org_id-Präfix, signierte URLs, niemals ein öffentlicher Bucket „alle Uploads“.
• Schema oder Datenbank pro Mandant nur, wenn Vertrag, Compliance-Checkliste oder ein echter lauter Nachbar es erzwingt. Migrationen über 200 Schemas sind ein Produkt, das Sie nicht wollten.

4. Abrechnung ist eine Funktion, kein Plugin für später

Wenn niemand zahlen kann, haben Sie kein SaaS. Checkout würde ich in Woche zwei auf den kritischen Pfad legen, auch wenn der Rest der App dünn ist. Eine Phase „wir rechnen manuell ab“ ist für die ersten fünf Design-Partner okay - danach muss die Karte funktionieren.

• Stripe Billing (oder der Prozessor, den Ihr erster Markt wirklich nutzt): Products, Prices, Customer Portal, Webhooks. Keine Kartennummern speichern. Keine Mahn-Engine schreiben.
• Ein oder zwei Pläne, nicht sieben. Testphase mit klarem Ende. Danach: nur Lesen oder harter Block - eines wählen und in der Oberfläche sagen.
• Preis für etwas, das Kunden verstehen: Plätze, Projekte oder Monatsvolumen. Nutzungsabrechnung ist mächtig und leicht falsch; starten Sie mit Platz oder Pauschale, bis Sie wissen, was „Nutzung“ überhaupt ist.
• Webhooks sind die Quelle der Wahrheit für „haben sie bezahlt?“. Ihre Datenbank spiegelt Stripe (oder Paddle). Ein Cron, der rät, sperrt zahlende Kunden aus.

5. Der Stack, den ich nehmen würde (und wie er sich vom Site-MVP unterscheidet)

Der Web-Standard bleibt: Next.js, TypeScript, Tailwind, Postgres. SaaS fügt ein paar Teile hinzu, die eine Marketing-Site nicht braucht - und braucht immer noch kein Service-Mesh.

• Auth, der Organisationen versteht: Clerk, WorkOS, Auth.js plus Mitgliedstabelle - kein globales „eingeloggt“-Flag.
• Hintergrundjobs ab Tag eins, wenn etwas langsam oder wiederholbar ist: E-Mails, Stripe-Webhooks, Exporte, LLM-Aufrufe. Eine einfache Warteschlange (Inngest, Trigger.dev oder ein Worker auf dem VPS) schlägt setTimeout in einer Serverless-Funktion.
• Transaktions-E-Mail ab Minute eins: Einladung, Beleg, „Ihre Testphase endet Freitag.“ Kommt die Mail nicht an, fühlt sich das Produkt tot an.
• Feature Flags für Pläne (can_export, seat_limit), nicht if (org.plan === "pro") in fünfzig Dateien.
• Hosting: Vercel plus gehostetes Postgres ist okay, bis ein Worker oder Residenz etwas anderes sagt. Eine Region reicht. Mehrere Regionen sind später.

6. Der Einstieg ist das Produkt der ersten Stunde

Leere SaaS-Dashboards konvertieren nicht. Die erste Sitzung würde ich als Aufgabe gestalten, nicht als Rundgang: Workspace anlegen, den ersten echten Datensatz importieren oder tippen, ein Teammitglied einladen, ein Ergebnis sehen. Tooltips über einer leeren Tabelle sind kein Einstieg.

• Ein Beispiel-Workspace ist okay, wenn er klar unecht ist und einen Klick von „mit meinen Daten starten“ entfernt.
• Aktivierungsmetrik: sie haben die Kernaufgabe einmal geschafft, nicht „registriert“. Das messen. Das verkaufen.
• Einstellungen dürfen hässlich sein. Der Leerzustand des Hauptbildschirms nicht.

7. Betrieb: wie Sie Menschen unterstützen, die Sie nie getroffen haben

An dem Tag, an dem eine zahlende Organisation schreibt „ich sehe meine Rechnungen nicht“, brauchen Sie einen Weg ohne Production-SSH. Ein schlankes internes Admin würde ich vor dem zehnten Kunden bauen, nicht nach dem ersten Vorfall.

• Admin: Organisation finden, Plan und letzten Webhook sehen, schreibgeschützt impersonieren, Einladung neu senden. Impersonation prüfen.
• Logs mit org_id und Request-ID. „Es ist fehlgeschlagen“ ohne Mandant ist keine Logzeile, es ist ein Schulterzucken.
• Backups, die Sie einmal wiederhergestellt haben. Nachts reicht am Anfang; ungetestete Backups sind eine Geschichte, die Sie sich erzählen.
• Eine Statusseite kann warten. Eine Mail „wir liegen, das wissen wir“ nicht.

8. Was ich im ersten Jahr nicht bauen würde

Großes SaaS ist ein Museum von Funktionen, die sich später bezahlt gemacht haben. Das Museum zu kopieren ist, wie man die eine Aufgabe verfehlt.

• SSO, SCIM und ein 40-Seiten-Sicherheitsfragebogen erst, wenn ein echter Deal daran hängt. Dann sind sie der Sprint, keine Nebenquest.
• Eine öffentliche API und ein Integrationsmarktplatz. Ein Zapier oder ein CSV-Export entblockt oft denselben Käufer.
• Eigene Domains pro Mandant, White-Label und Theme-Studio. Ein Logo-Upload reicht für das meiste frühe B2B.
• KI überall. Eine Stelle, wo Sprache die Aufgabe ist (Suche, Entwürfe, Extraktion), mit Schema und abrechenbarem Zähler. Keine Chat-Blase auf jedem Bildschirm.

9. Eine Reihenfolge, der ich wirklich folgen würde

Dieselbe Kalender-Ehrlichkeit wie beim MVP, mit SaaS-Meilensteinen. Hat eine Woche keinen Mandanten, keine Zahlung oder keine Aufgabe, ist sie keine SaaS-Woche.

• Woche 0: Aufgabe, Käufer, Plan, Abbruchzahl benennen (z. B. fünf zahlende Organisationen in 90 Tagen oder Stopp). Nicht-Ziele auf einer Seite.
• Wochen 1-2: Organisation + Mitgliedschaft + ein Happy Path in Produktion + Stripe Test Mode. Isolationstests: User A darf User B nicht sehen.
• Wochen 3-4: Live-Abrechnung, Einladungen, Mails, Einstieg im Leerzustand, schlankes Admin. Named Companies zeigen, nicht „dem Internet“.
• Tage 30-90: Aktivierung und Abwanderungsgründe ansehen. Die eine Integration oder den Report hinzufügen, für den sie zahlen. Kein zweites Produkt.

Fazit: vermieten Sie eine Aufgabe, keine Plattform

SaaS würde ich genauso unglamourös bauen wie ein MVP, plus die Teile, die vielen Firmen ein System geben: Workspace, Rechnung, Wand zwischen Mandanten, eine erste Stunde, die nicht leer ist, und ein Admin, damit Support keine Root-Shell ist. Der Stack darf langweilig bleiben. Das Produkt nicht vage.

Wenn Sie einen Ablauf haben, für dessen Wiederholung Ihnen schon mehrere Firmen zahlen, und Sie daraus ein Produkt wollen statt einem Haufen Custom-Deploys - schreiben Sie über den Kontaktbereich. Wir können das Mandantenmodell, den ersten Plan und einen Ausschnitt benennen, der eine Karte nimmt, ohne Salesforce zu spielen.