Auth, Billing, Compliance: die unsichtbaren Bausteine eines SaaS

Warum Login, Billing und Datenschutz die teuren Bausteine eines SaaS sind

Wenn du ein SaaS planst, drehen sich die ersten Gespräche fast immer um Features. Welcher Workflow löst das Problem deiner Kundschaft, wie sieht das Dashboard aus, was macht das Produkt besonders. Das ist richtig so, denn dafür bezahlen die Leute am Ende. Untergehen dabei drei Bausteine, die jedes SaaS braucht, egal was es tut: wer darf rein (Auth), wie kommt Geld herein (Billing) und wie gehst du mit den Daten um (Compliance).

Diese drei werden unterschätzt, weil sie unsichtbar sind. Ein gutes Login fällt niemandem auf. Eine korrekte Rechnung löst keine Begeisterung aus. Und Datenschutz wird erst sichtbar, wenn er fehlt. Diese Unsichtbarkeit verleitet dazu, sie als Kleinigkeit zu behandeln, die man später schnell macht. Tatsächlich sind es die Bausteine, an denen Projekte Wochen verlieren: Sie sitzen tief im Produkt und lassen sich nachträglich nur schwer ändern. Wir kennen das aus dem Betrieb unserer eigenen Produkte Wortfreunde und Reazon. Was hier sauber gebaut ist, merkt man jahrelang nicht. Was abgekürzt wurde, holt einen genau dann ein, wenn am wenigsten Zeit dafür ist.

Gehen wir die drei der Reihe nach durch.

Auth: Login, Rollen und SSO sauber trennen

Authentifizierung beantwortet, wer jemand ist. Autorisierung beantwortet, was diese Person darf. Beides wird gern in einen Topf geworfen, sind aber getrennte Probleme. Das zweite ist meist das grössere.

Der Login selbst, E-Mail und Passwort, wirkt simpel. Schau aber genauer hin, und eine ganze Kette hängt daran: Passwort vergessen, E-Mail bestätigen, Sessions, die ablaufen, Schutz gegen Brute-Force, Zwei-Faktor-Authentifizierung. Jeder Punkt ist für sich klein. Zusammen sind sie ein Projekt, und eines, in dem du dir keine Fehler leisten kannst, denn ein Loch im Login betrifft sofort alle.

Die eigentliche Komplexität kommt mit den Rollen. In einem B2B-SaaS reicht selten ein einzelner Nutzertyp. Du hast Administratorinnen, normale Mitglieder, vielleicht eine reine Leserolle, dazu das Konzept der Organisation oder des Teams: Mehrere Personen gehören zur gleichen Firma, teilen sich Daten, sehen aber nicht zwingend dasselbe. Wer darf andere einladen, wer das Abo verwalten, wer Daten exportieren. Diese Rechtelogik zieht sich durch jede einzelne Funktion deines Produkts. Baust du sie erst nachträglich ein, musst du jede Funktion noch einmal anfassen.

SSO (Single Sign-on) bedeutet, dass sich Nutzer mit einem bestehenden Konto anmelden, etwa Google, Microsoft oder dem firmeneigenen Identity-Provider. Für Privatkunden ist Login mit Google eine Bequemlichkeit. Im Unternehmenskontext wird SSO oft zur harten Voraussetzung. Grosse Kunden kaufen schlicht nicht, wenn sie Mitarbeitende nicht über ihr zentrales System verwalten können. Das solltest du früh wissen, denn es entscheidet, ob SSO ein späteres Verkaufsargument ist oder von Anfang an ein Muss.

Im MVP reicht meist ein solider E-Mail-Login mit Passwort-Reset, ein bis zwei Rollen und das Organisations-Konzept zumindest im Datenmodell vorgesehen, auch wenn die Oberfläche dafür noch dünn ist. SSO und feingranulare Rechte darfst du verschieben, solange das Fundament sie später zulässt. Bei der Umsetzung musst du nicht von null anfangen: Dienste wie Auth0, Clerk oder WorkOS, oder die Auth-Funktion von Plattformen wie Supabase, nehmen dir Login, Reset, 2FA und oft auch SSO ab. Du gibst ein Stück Kontrolle ab und sparst dafür einen grossen Teil der Arbeit, die ohnehin niemand sieht.

Billing: warum nach dem Bezahlknopf die Arbeit erst anfängt

Billing klingt nach Bezahlknopf einbauen, und der ist tatsächlich schnell erledigt. Das Problem ist alles, was danach kommt.

Die meisten SaaS verkaufen Abonnements, und ein Abo ist ein Zustand, der sich über die Zeit verändert. Jemand startet im kleinen Tarif, bucht hoch, im nächsten Monat wieder runter, pausiert, kündigt zum Periodenende, kommt zurück. Bei monatlicher und jährlicher Zahlung kommen anteilige Verrechnungen dazu, das sogenannte Proration: Wer mitten im Monat wechselt, zahlt nicht den vollen Betrag. Diese Logik sauber abzubilden ist deutlich mehr Arbeit als die erste Zahlung. Hinzu kommt der Umgang mit fehlgeschlagenen Zahlungen. Eine Karte läuft ab, die Abbuchung scheitert, und du brauchst eine Strategie, wie oft du es erneut versuchst und ab wann du den Zugang sperrst.

Dann die Rechnungen. Eine korrekte Rechnung ist ein rechtliches Dokument mit festen Pflichtangaben, fortlaufender Nummerierung und Aufbewahrungspflicht. Das ist kein PDF, das man nebenbei generiert, sondern etwas, das mit deiner Buchhaltung zusammenpassen muss.

Am meisten unterschätzt wird die Steuer. In der Schweiz hast du die Mehrwertsteuer, verkaufst du in die EU, kommt deren Umsatzsteuer dazu, und die richtet sich danach, wo deine Kundschaft sitzt und ob sie Firma oder Privatperson ist. Sobald du digital über Grenzen verkaufst, betrifft dich das schneller, als dir lieb ist. Steuerlogik willst du nicht selbst programmieren, denn die Regeln ändern sich und Fehler werden teuer.

Im MVP genügen oft ein oder zwei klar getrennte Tarife, monatliche Abrechnung, ein Zahlungsanbieter. Spar dir am Anfang jeden exotischen Sonderfall im Tarifmodell, denn jede Variante vervielfacht die Fälle, die du testen musst. Bei der Umsetzung ist die Antwort hier fast immer ein etablierter Anbieter. Stripe und vergleichbare Dienste übernehmen Abos, Proration, Rechnungen, Wiederholungsversuche bei fehlgeschlagenen Zahlungen und in weiten Teilen die Steuerberechnung. Selbst nachzubauen, was Stripe bietet, lohnt sich praktisch nie. Wie dieser Aufwand die Gesamtkosten beeinflusst, ordnen wir in was kostet ein MVP genauer ein.

Compliance: Datenschutz und Datenhaltung von Anfang an mitdenken

Compliance macht am meisten Angst und wird am wenigsten verstanden. Dabei lässt sie sich auf eine handhabbare Frage herunterbrechen: Du speicherst Daten über Menschen, also musst du wissen, welche, warum, wo und wie lange.

In der Schweiz gilt das revidierte Datenschutzgesetz, in der EU die DSGVO. Sobald du Kundinnen oder Nutzer in der EU hast, betrifft dich die DSGVO mit. Beide verlangen im Kern Ähnliches: Du darfst nur Daten erheben, die du brauchst, musst transparent machen, was du tust, und Betroffene haben Rechte, etwa auf Auskunft und Löschung. Praktisch heisst das, dein Produkt muss von Anfang an wissen, wo welche personenbezogenen Daten liegen. Verlangt jemand Löschung, musst du sie finden und entfernen können.

Datenhaltung ist die technische Seite davon. Wo stehen deine Server, in der Schweiz, in der EU, anderswo. Für bestimmte Kundengruppen, etwa im Gesundheitswesen oder bei Behörden, ist der Standort kein Detail, sondern eine Bedingung für den Kauf. Dazu gehören Backups, die du im Ernstfall auch wirklich einspielen kannst, eine Verschlüsselung der Daten und eine saubere Trennung, damit eine Organisation niemals die Daten einer anderen sieht. Dieser letzte Punkt, die Mandantentrennung, hängt direkt mit dem Organisations-Konzept aus dem Auth-Abschnitt zusammen. Rechtelogik und Datentrennung sind zwei Seiten derselben Sache.

Unterschätzt wird Compliance, weil sie keine Funktion ist, die man abhakt, sondern eine Eigenschaft, die das ganze System durchzieht. Datenschutz lässt sich nicht am Schluss dazupacken, wenn das Datenmodell ihn nicht vorsieht. Hier scheitern Projekte still, lange bevor es ein rechtliches Problem gibt, weil eine späte Korrektur das halbe Produkt umbaut. Mehr dazu, woran solche Vorhaben kippen, steht in warum SaaS-Projekte scheitern.

Im MVP reicht eine nüchterne Bestandsaufnahme, welche personenbezogenen Daten du wirklich erhebst, und der Verzicht auf alles Übrige. Dazu eine Datenschutzerklärung, ein bewusst gewählter Serverstandort, Verschlüsselung, ein funktionierendes Backup und eine Löschfunktion, die ihren Namen verdient. Ein Zertifikat brauchst du nicht am ersten Tag, ein Datenmodell, das die Grundregeln respektiert, sehr wohl. Bei der Umsetzung helfen Hosting in der Schweiz oder EU, Auftragsverarbeiter mit passenden Verträgen und Auth- sowie Datenbankdienste, die Mandantentrennung von Haus aus mitbringen. Den Rahmen, in dem diese Entscheidungen fallen, beschreiben wir bei der SaaS-Produktentwicklung.

Wann du selbst baust und wann du kaufst

Die drei Bausteine teilen eine Eigenschaft: Sie kosten am Anfang Disziplin und später sehr viel mehr, wenn sie fehlen. Auth, Billing und Compliance sind keine Features, die du an- und ausschaltest, sondern das Fundament, auf dem alles andere steht. Das Datenmodell muss Organisationen und Rollen kennen, bevor die erste richtige Funktion entsteht. Die Abrechnung muss zum Tarifmodell passen, bevor du den ersten Kunden hast. Der Datenschutz gehört in den Aufbau, nicht in eine spätere Aufräumrunde.

Wann lohnt sich der Eigenbau dann überhaupt? Selten. Bei keinem der drei fängst du bei null an, und in den meisten Fällen ist der fertige Baustein die richtige Wahl. Selbst bauen ergibt nur Sinn, wo dein Produkt genau an diesem Punkt sein Geld verdient: Wenn deine Rechtelogik so eigen ist, dass kein Anbieter sie abbildet, oder wenn ein regulatorischer Rahmen vollständige Kontrolle über die Datenhaltung verlangt. In jedem anderen Fall sparst du dir mit Auth0, Stripe und Hosting in der Schweiz oder EU die unsichtbare Arbeit und steckst die Zeit ins Feature, das verkauft.

Die eigentliche Kunst besteht darin, die richtigen Bausteine auszuwählen und sauber zu verbinden. Wir bauen Produkte nicht nur, wir betreiben mit Wortfreunde und Reazon eigene, und dieser Betrieb ist der Grund, warum wir Auth, Billing und Compliance ernst nehmen, bevor sie wehtun. Was im MVP wirklich nötig ist und was warten kann, läuft am Ende auf dieselbe Frage hinaus: Lege ein Fundament, das spätere Schritte trägt, und verschiebe alles, was sich ohne Umbau nachrüsten lässt.