Eine SaaS-Plattform ist kein Produkt. Sie ist ein Geschäftsmodell.

Was ist das?

Eine SaaS-Plattform ist ein einzelnes Software-System, das gleichzeitig für viele Kunden läuft. Jeder Kunde hat seinen eigenen abgeschotteten Bereich: eigene Nutzer, eigene Daten, eigene Konfiguration, eigene Abrechnung. Diese Abschottung nennt man Mandantenfähigkeit oder Multi-Tenancy. Der Kernpunkt: Sie pflegen eine Codebasis, nicht hundert. Updates kommen allen Kunden gleichzeitig zugute. Fehler werden einmal gefixt. Features werden einmal gebaut.

Wie sieht das aus?

Drei Szenarien, die oft als "SaaS" bezeichnet werden, es aber nicht sind. Erstens: Eine Web-App mit einem einzigen Kunden. Das ist keine Plattform, das ist eine Individualsoftware im Browser. Zweitens: Für jeden Kunden eine separate Kopie der Software installiert. Das ist Hosted Software, pflegbar, aber teuer im Betrieb. Drittens: Eine Plattform ohne Abrechnung, auf der Kunden nur manuell hinzugefügt werden. Das ist ein geschlossenes System, keine skalierende Plattform. Richtiges SaaS: eine Codebasis, automatischer Self-Service, integrierte Abrechnung, klare Daten-Trennung zwischen Kunden. Alles drunter ist etwas anderes.

Warum ist das wichtig?

Der Unterschied ist wirtschaftlich entscheidend. Eine echte SaaS-Plattform hat Skalen-Vorteile: Jeder zusätzliche Kunde erhöht den Umsatz, aber kaum die Kosten. Eine "SaaS-ähnliche" Lösung, bei der jeder Kunde eigene Betreuung, eigene Installation oder eigene Anpassung braucht, hat diese Vorteile nicht und ist deshalb im Markt meist ein Auslaufmodell. Wer heute in einem SaaS-Markt antritt, muss die echte Form bauen.

Wie wir das bauen

Wir starten jedes SaaS-Projekt mit einer klaren Architektur-Entscheidung: Wo lebt die Kunden-Trennung? Im Datenmodell, in der Infrastruktur, oder auf beiden Ebenen? Welche Daten dürfen kundenübergreifend genutzt werden (etwa anonymisierte Benchmarks), welche niemals? Wie werden Features pro Kunde aktivierbar, ohne eine Verzweigung der Codebasis? Diese Grundsatz-Entscheidungen treffen wir in der ersten Woche. Sie tragen die ganze Plattform. Später lassen sie sich nur noch mit hohem Aufwand ändern.

Typische Anwendungsfälle

• B2B-Produkte mit planbar wiederkehrenden Arbeitsabläufen
• Branchenlösungen, die viele gleichartige Kunden ansprechen
• Tools, die in Teams genutzt werden und über Nutzer skalieren
• Plattformen, die eigene Daten pro Kunde verarbeiten müssen

Was ist das?

Das Datenmodell einer SaaS-Plattform beantwortet drei Fragen: Wie wird jeder Kunde eindeutig identifiziert? Wie werden die Daten so getrennt, dass kein Kunde je Daten eines anderen sehen kann? Wie werden die Daten so geschnitten, dass Abfragen schnell bleiben, auch wenn die Plattform wächst? Die Antwort ist nicht "eine Datenbank pro Kunde" (teuer, skaliert nicht) und nicht "alle in einem Topf mit einer Filter-Spalte" (fragil, fehleranfällig). Die Antwort ist fast immer eine Kombination: strikte Trennung auf Daten-Ebene mit harter, nicht umgehbarer Zugriffskontrolle.

Wie sieht das aus?

Eine typische Situation: Ein SaaS-Anbieter baut in den ersten Monaten alles mit einer einzigen Datenbank und filtert über eine Mandanten-Spalte. Läuft reibungslos, bis eine Entwicklerin beim Refactoring einen Filter vergisst. In einer internen Ansicht sehen plötzlich Kunden Daten anderer Kunden. Das Vertrauen ist in Stunden zerstört, die rechtlichen Folgen sind monatelang sichtbar. Wir bauen so, dass ein vergessener Filter gar nicht erst durchkommt. Die Datenbank selbst setzt die Trennung durch, nicht nur der Anwendungscode. Das ist langweilige, unspektakuläre Arbeit am ersten Tag, und Gold wert am tausendsten.

Warum ist das wichtig?

Fast jede Horror-Geschichte über SaaS-Datenpannen geht auf dieselbe Ursache zurück: Mandanten-Trennung, die nur im Anwendungscode lebt. Wenn eine einzige vergessene Zeile genügt, um die Grenze zu durchbrechen, ist die Grenze nicht stabil. Das gilt besonders im DACH-Markt: Enterprise-Kunden und regulierte Branchen kaufen nicht von Anbietern, die Trennung nicht auf Infrastruktur-Ebene belegen können. Ein sauberes Datenmodell ist damit nicht nur eine technische Entscheidung, sondern ein direkter Vertriebs-Vorteil.

Wie wir das bauen

Wir arbeiten mit Zugriffskontrolle auf Datenbank-Ebene, sodass jede Abfrage automatisch auf die Daten des angemeldeten Kunden beschränkt ist, egal, ob sie aus der Anwendung oder aus einem Admin-Tool kommt. Wir trennen klar zwischen kundenspezifischen Daten, kundenübergreifenden Meta-Daten und aggregierten, anonymisierten Analyse-Daten. Und wir bauen von Beginn an Mechanismen für Kunden-Export (Datenhoheit), Kunden-Löschung (DSGVO), und Migration zwischen Plänen. Das spart später viel Pflicht-Arbeit, die sonst im schlechtesten Moment kommt.

Typische Anwendungsfälle

• B2B-Plattformen mit Geschäfts-kritischen Kunden-Daten
• Anbieter in regulierten Branchen (Finanzen, Gesundheit, Recht)
• Plattformen mit mehreren Unterkategorien (z. B. Standorte, Abteilungen)
• Systeme mit anonymisierten kundenübergreifenden Benchmarks

Was ist das?

Eine moderne SaaS-Abrechnung muss mehr können als nur "monatlich X Euro abbuchen". Sie muss Pläne unterstützen (z. B. Starter, Business, Enterprise), Nutzung abrechnen (API-Calls, Speicher, verarbeitete Dokumente), Upgrades und Downgrades während eines Abrechnungs-Zeitraums sauber einpreisen, mehrere Zahlungsarten akzeptieren, Steuern korrekt berechnen (EU, Schweiz, USA, unterschiedliche Regeln), Rechnungen rechtssicher ausstellen, und auf Ausnahmen wie Mahnungen, Zahlungs-Ausfälle, Chargebacks reagieren. Das ist keine Nebensache. Das ist ein eigenes Modul.

Wie sieht das aus?

Ein typisches Szenario: Ein Kunde bucht den Starter-Plan am 3. des Monats, upgrade am 17. auf Business, fügt am 24. drei zusätzliche Nutzer hinzu, und am Monatsende wechselt die Firma ihre Zahlungsmethode. Eine solide Abrechnung muss das alles sauber abrechnen: anteilig für die ersten 14 Tage Starter, anteilig für die 13 Tage Business, inklusive zusätzliche Nutzer für die letzte Woche, alles auf einer einzigen Rechnung mit korrekter Mehrwertsteuer. Und wenn die Zahlung fehlschlägt, muss der Kunde nicht sofort gesperrt werden, sondern drei Erinnerungen bekommen, bevor Schritte folgen. Solche Szenarien passieren ständig. Sie müssen von Anfang an mitgedacht sein.

Warum ist das wichtig?

Abrechnungs-Fehler sind das Schlimmste, was in einer SaaS-Plattform passieren kann. Sie kosten direkt Vertrauen, sie kosten Zeit in Support, sie kosten manchmal Kunden. Gleichzeitig ist die Abrechnung der Punkt, an dem Kunden Ihre Ehrlichkeit und Professionalität messen. Eine transparente, nachvollziehbare, verlässliche Abrechnung ist einer der stärksten Loyalitäts-Faktoren einer SaaS-Plattform. Eine intransparente oder fehlerhafte ist einer der stärksten Kündigungs-Gründe.

Wie wir das bauen

Wir setzen auf bewährte Abrechnungs-Infrastruktur mit einer eigenen Schicht darüber, die Ihre Geschäfts-Logik trägt: welche Features in welchem Plan, wie Upgrades einpreisen, wann Mahnungen laufen. Alle Abrechnungs-Ereignisse werden geloggt, sodass Sie jeden Rechnungs-Posten bis zum auslösenden Kunden-Ereignis zurückverfolgen können. Kunden sehen eine klare Rechnungs-Ansicht mit allen Details. Und wichtig: wir bauen die Abrechnung so, dass Preis-Änderungen in der Zukunft nicht zu einem Riesen-Projekt werden.

Typische Anwendungsfälle

• Mehrere Preis-Pläne mit Feature-Unterschieden
• Nutzungs-basierte Abrechnung (pro API-Call, pro Dokument, pro Nutzer)
• Jahres-Abos mit Rabatt-Logik
• Mehrwertsteuer-Handling in internationalen Märkten
• Rechnungstellung an Firmen mit speziellen Zahlungs-Konditionen

Was ist das?

Jede SaaS-Plattform braucht ein System, das drei Fragen beantwortet: Wer ist dieser Nutzer (Authentifizierung)? Zu welchem Kunden gehört er (Mandant)? Welche Aktionen darf er im Rahmen dieses Kunden durchführen (Rollen und Rechte)? Diese drei Ebenen müssen sauber getrennt sein, damit das System flexibel bleibt. Hinzu kommen moderne Anforderungen: Single-Sign-On für Enterprise-Kunden, Zwei-Faktor-Pflicht für bestimmte Rollen, Einladungs-Workflows für Team-Mitglieder, Gast-Zugänge mit Ablaufdatum.

Wie sieht das aus?

Eine Plattform für ein Beratungsunternehmen hat drei Rollen: Beraterinnen (erstellen Inhalte, sehen eigene Kunden), Team-Leitung (sieht alle Beraterinnen im Team, weist zu), Admin (verwaltet Pläne, Zahlungen, Rollen). Später kommt ein vierter Fall dazu: externe Kunden sollen Live-Dashboards sehen, aber nichts verändern. Ein fünfter Fall: Audit-Nutzer der Wirtschaftsprüfung mit Lese-Zugriff auf alles, aber nur für einen bestimmten Zeitraum. Ein starres Rollen-Modell, das alle Rollen hart codiert, bricht beim dritten Erweiterungs-Wunsch. Ein gut gebautes, berechtigungs-basiertes System bildet alle fünf Rollen ab, ohne die Codebasis anzufassen.

Warum ist das wichtig?

Falsch gesetzte Rechte sind die Hauptquelle für Sicherheits-Pannen in SaaS-Plattformen. Beispiele: Ein Team-Mitglied kann versehentlich Rechnungen sehen. Ein ehemaliger Mitarbeiter hat nach der Kündigung noch Zugang. Ein Gast kann mehr als geplant. Solche Pannen sind selten böse gemeint, aber immer teuer: juristisch, finanziell und reputationsseitig. Ein sauber gebautes Rollen-System verhindert das, indem es Rechte zentral, nachvollziehbar und testbar macht.

Wie wir das bauen

Wir arbeiten mit einem modernen, berechtigungs-basierten Modell: Jede Aktion in der Plattform verlangt eine bestimmte Berechtigung. Rollen sind nur Bündel von Berechtigungen. So lassen sich neue Rollen definieren, ohne Code zu ändern. Wir unterstützen Standards für Enterprise-Anmeldung, sichere Zwei-Faktor-Authentifizierung für privilegierte Rollen, und Einladungs-Flows mit Ablauf-Logik. Alle Berechtigungs-Entscheidungen werden geloggt. Wer hat wann was gemacht, ist jederzeit nachvollziehbar.

Typische Anwendungsfälle

• B2B-Plattformen mit Teams unterschiedlicher Größe
• Enterprise-Verkauf mit Single-Sign-On-Anforderung
• Branchen mit Audit-Anforderungen (Finanz, Gesundheit, Recht)
• Plattformen mit externen Kollaborations-Partnern
• Mehrstufige Freigabe-Prozesse

Was ist das?

Performance in SaaS-Plattformen ist kein statisches Feature. Sie verschiebt sich mit dem Wachstum. In den ersten Monaten reicht fast jede Architektur. Ab dem zehnten zahlenden Kunden zeigen sich erste Engpässe. Ab dem hundertsten werden sie geschäftskritisch. Gute Plattformen antizipieren das. Sie werden so gebaut, dass sie unter Last in messbaren Schritten optimierbar sind: Caching, Index-Setzung, Query-Optimierung, Hintergrund-Verarbeitung für langsame Jobs, später horizontale Skalierung. Schlechte Plattformen werden bei 50 Kunden unbenutzbar und erfordern eine komplette Neu-Architektur.

Wie sieht das aus?

Ein Szenario, das wir oft sehen: Eine Plattform, die mit zehn Pilot-Kunden wunderbar lief, wird bei hundert Kunden langsam. Der erste Instinkt ist, mehr Server zu buchen. Das löst das Problem kurz, ist aber nicht nachhaltig. Die wirkliche Ursache ist meist eine Handvoll fehlender Datenbank-Indizes, ein unoptimierter Dashboard-Query, und das Fehlen von Caching für häufig gelesene Daten. Wir haben Plattformen gesehen, bei denen ein Tag gezielter Optimierung die Ladezeiten um den Faktor zehn verbessert hat, ohne zusätzliche Infrastruktur-Kosten.

Warum ist das wichtig?

Performance ist ein Vertrauens-Faktor. Eine Plattform, die sich zäh anfühlt, wirkt unprofessionell, unabhängig davon, wie gut die Features sind. Umgekehrt gehört es zu den größten Überraschungen für Kunden, dass eine SaaS-Plattform Jahr um Jahr schneller wird, obwohl sie mehr kann. Das passiert nicht von allein. Das ist bewusstes Engineering. Und es zahlt sich aus: Schnelle Plattformen haben höhere Bindungsraten und bessere Mundpropaganda.

Wie wir das bauen

Wir bauen von Beginn an eine Performance-Grundlage: saubere Datenmodell-Struktur mit den richtigen Indizes, Abfragen, die nicht mit dem Kunden-Volumen linear wachsen, Caching-Schichten für teure Lese-Operationen, Hintergrund-Jobs für alles, was nicht sofort antworten muss (E-Mail-Versand, Report-Generierung, Datenaufbereitung). Wir messen laufend, wo Zeit verloren geht, und optimieren gezielt die Stellen, die wirklich wehtun. Die größten Fallen (zu große Dashboards mit vielen gleichzeitigen Abfragen, zu detaillierte Listen ohne Paginierung, zu viel unnötige Berechnung) kennen wir aus vielen Projekten und vermeiden sie proaktiv.

Typische Anwendungsfälle

• Plattformen mit datenintensiven Dashboards
• SaaS-Produkte mit wachsendem Kunden-Stamm
• Analyse-Werkzeuge mit großen Datenmengen
• Plattformen mit gleichzeitiger Nutzung durch viele Team-Mitglieder

Was ist das?

Sobald Ihre Plattform ernsthaft größere Kunden adressiert, wird Sicherheit von einem "schönen Extra" zu einem verkaufs-entscheidenden Thema. Konkrete Anforderungen: wo liegen die Daten geografisch, wer hat administrativen Zugang, wie wird Authentifizierung abgesichert, welche Verschlüsselungs-Standards laufen, wie werden Backups gehandhabt, was passiert bei einem Vorfall, welche Audits wurden durchgeführt. Wer diese Fragen nicht in einem Satz beantworten kann, verliert den Pitch. Wer sie souverän beantwortet, gewinnt Vertrauen noch vor dem ersten Feature-Gespräch.

Wie sieht das aus?

Ein Gespräch, das wir kennen: Ein Enterprise-Kunde ist technisch begeistert von einer SaaS-Plattform und schon kurz vor Unterschrift. Dann schickt der Datenschutzbeauftragte einen Fragebogen mit vierzig Punkten. Die Startup-Plattform kann die Hälfte nicht beantworten, bei einem Drittel gibt es Baustellen. Der Deal fällt durch, nicht weil das Produkt schlecht wäre, sondern weil die Hausaufgaben in Sicherheit und Compliance fehlen. Eine SaaS-Plattform, die DACH-Enterprise bedienen will, muss diesen Fragebogen ohne Zögern beantworten können.

Warum ist das wichtig?

Im DACH-Raum ist Vertrauen das Kapital, das ein SaaS-Anbieter sich erst erarbeiten muss. Sicherheit ist keine Pflicht-Übung, sondern Voraussetzung für jeden ernsthaften Deal. Gleichzeitig sinkt der Aufwand, wenn man Sicherheit früh einbaut, und steigt exponentiell, wenn man sie nachrüsten muss. Unsere Faustregel: Sicherheit ist Bauprinzip, nicht Feature. Jede Architektur-Entscheidung hat eine Sicherheits-Dimension, die sofort mitgedacht wird.

Wie wir das bauen

Wir bauen standardmässig EU-basierte Infrastruktur mit klaren Auftragsverarbeitungs-Verträgen, Ende-zu-Ende verschlüsselte Daten im Transport und in der Ablage, strenge Zugriffskontrolle auf allen Ebenen (Datenbank, API, Admin-Werkzeuge), ein vollständiges Audit-Log für kritische Ereignisse, regelmäßige Sicherungen mit getesteten Wiederherstellungs-Prozeduren, und ein klares Vorfall-Konzept. Für größere Kunden bereiten wir standardisierte Sicherheits-Dokumente vor, die bei Ausschreibungen direkt beigelegt werden können. Das verkürzt Verkaufs-Zyklen erheblich.

Typische Anwendungsfälle

• SaaS-Plattformen im DACH-Enterprise-Verkauf
• Produkte in regulierten Branchen (Finanz, Gesundheit, Recht, Versicherung)
• Anbieter mit Ausschreibungs-Pflicht (Öffentlicher Sektor, Konzerne)
• Plattformen mit personenbezogenen oder sensiblen Daten

Was ist das?

Onboarding ist der gesamte Prozess vom ersten Klick eines Kunden bis zum Moment, in dem er seinen ersten messbaren Nutzen aus der Plattform zieht. Dieser Prozess besteht aus vielen kleinen Schritten: Registrierung, E-Mail-Bestätigung, Konto-Einrichtung, erste Konfiguration, Einladung von Team-Mitgliedern, erste Nutzung eines Kern-Features. Jeder einzelne Schritt ist ein potenzieller Aussteigepunkt. Ein gut gebautes Onboarding reduziert diese Aussteigepunkte auf ein Minimum und führt den Kunden systematisch zum ersten Erfolg.

Wie sieht das aus?

Zwei SaaS-Plattformen im gleichen Markt. Plattform A hat ein klassisches Onboarding: Registrierung, Bestätigungs-Mail, leerer Dashboard, Hilfe-Dokumentation in der Sidebar. 60 Prozent der Nutzer kommen nie zurück. Plattform B hat ein geführtes Onboarding: Nach der Registrierung ein kurzer Konfigurations-Assistent, automatisch befüllte Beispiel-Daten zum Ausprobieren, ein klarer erster Schritt mit sichtbarem Ergebnis, eine E-Mail-Sequenz, die in den ersten Tagen konkret hilft. 85 Prozent der Nutzer sind nach einer Woche aktiv. Gleicher Funktions-Umfang, völlig andere Wirtschaftlichkeit. Der Unterschied entsteht nur im Onboarding.

Warum ist das wichtig?

Onboarding ist der hebelstärkste Bereich in einer SaaS-Plattform. Jede Verbesserung wirkt nicht nur auf den ersten Tag, sondern auf die ganze Nutzungszeit des Kunden. Kunden, die eine positive erste Erfahrung haben, nutzen mehr Features, empfehlen die Plattform häufiger, und kündigen seltener. Wir empfehlen jeder Plattform, in den ersten sechs Monaten nach Live-Gang einen signifikanten Teil der Entwicklungs-Zeit in die Onboarding-Optimierung zu stecken. Die Rendite ist nirgends höher.

Wie wir das bauen

Wir bauen Onboarding nicht als Einmal-Projekt, sondern als messbaren, iterativen Prozess. Jeder Schritt wird mit Kennzahlen hinterlegt: Ausstiegsraten, Zeit pro Schritt, Rückkehr-Rate. Schwachstellen werden sichtbar und gezielt optimiert. Wir arbeiten mit automatisierten E-Mail-Sequenzen, die Kunden zur richtigen Zeit die richtige Hilfe geben, mit kontextuellen Hinweisen im Produkt, die genau dann erscheinen, wenn sie gebraucht werden, und mit einer minimalen ersten Konfiguration, die den Kunden nicht zuerst stundenlang arbeiten lässt, bevor er Nutzen sieht.

Typische Anwendungsfälle

• B2B-Plattformen mit Self-Service-Registrierung
• Produkte mit vielschichtiger Konfiguration
• SaaS-Tools für Teams (Einladungs- und Kollaborations-Flows)
• Freemium-Plattformen mit Conversion zum zahlenden Plan
• Branchen-Lösungen mit Setup-intensivem Ersteinstieg

Was ist das?

Eine SaaS-Plattform ist eine Investition, die sich typisch über Monate und Jahre refinanziert. Die wirtschaftliche Realität: In den ersten sechs bis neun Monaten entsteht vor allem Entwicklungs-Aufwand ohne nennenswerten Umsatz. Die nächsten sechs bis neun Monate bringen erste zahlende Kunden, aber meist noch im Defizit-Bereich. Der Break-Even kommt typisch im zweiten oder dritten Jahr, je nach Markt, Preisgestaltung und Vertriebs-Kanal. Wer diese Kurve nicht einplant, gerät in finanziellen Druck, der die Plattform zerstört, bevor sie ihre Chance hatte.

Wie sieht das aus?

Eine häufige Situation: Ein Gründer-Team startet mit zwölf Monaten Runway und erwartet, nach sechs Monaten zu leben von den Abos. Technisch ist das machbar, aber markt-seitig fast nie. B2B-SaaS-Verkaufs-Zyklen sind länger, Reputation muss aufgebaut werden, Wort-zu-Mund-Propaganda braucht Zeit. Nach sechs Monaten gibt es vielleicht fünf zahlende Kunden. Das reicht, um zu wissen, dass das Produkt funktioniert, aber nicht, um das Team zu finanzieren. Wir sprechen das offen an: Ein SaaS-Produkt braucht einen Bauplan, der zur Finanzierungs-Situation passt. Kürzer in manchen Fällen, länger in anderen, aber ehrlich durchgerechnet.

Warum ist das wichtig?

Der größte Fehler, den wir in SaaS-Projekten sehen, ist Überplanung auf der Feature-Seite und Unterplanung auf der wirtschaftlichen Seite. Das Produkt kann noch so gut sein. Wenn die Runway vor dem Break-Even endet, ist es aus. Wir möchten, dass unsere Partner erfolgreich sind, und das beginnt mit ehrlicher Planung: Was kann mit welchem Budget realistisch erreicht werden, welcher Markt wird wie adressiert, wann können erste Umsätze realistisch erwartet werden.

Wie wir das bauen

Wir starten jedes SaaS-Projekt mit einer wirtschaftlichen Landkarte: Was ist das Minimum Viable Product, das man live bringen kann? Was sind die nächsten Ausbau-Stufen, jeweils mit klarem Kunden-Nutzen? Wie sieht ein realistischer Kunden-Akquise-Plan aus? Welche Umsatz-Kurve ist bei welchem Marketing-Budget plausibel? Das sind keine Marketing-Folien. Das sind nüchterne Rechnungen mit konservativen Annahmen. Lieber überraschend gut als erwartet zu sehr enttäuschend. Und wir empfehlen, erst nach Beweis des Markts ein größeres Team aufzubauen, nicht davor.

Typische Anwendungsfälle

• Gründer-Teams mit begrenzter Initialfinanzierung
• Corporate-Innovation-Projekte mit Budget-Stufen
• Branchen-SaaS mit klarem ersten Ziel-Kundensegment
• Plattformen, die aus einem bestehenden Dienstleistungs-Geschäft skalieren