Das Problem ist validiert.
Gespräche, Pilotkunden oder ein bestehender manueller Service belegen, wer das Produkt warum nutzen und bezahlen soll.
SaaS-Plattformen
Der erste Kunde verzeiht fast alles. Der zehnte nicht mehr: Er will wissen, wie seine Daten von denen der anderen getrennt sind, er rechnet seine Rechnung nach, er fragt, was bei einem Ausfall passiert, und er ist womöglich so groß wie die ersten neun zusammen. Diese vier Antworten entstehen am Anfang oder gar nicht. Ich treffe sie mit Ihnen, bevor sie teuer werden, und im Zweifel sage ich Ihnen, dass Ihr heutiger Aufbau schon reicht.
Der Zuschnitt als abgeschlossenes Mandat von einer Woche, zum Festpreis: entschieden wird im Gespräch, geschrieben wird in Ihrem Repository. Der Produktivbau darauf danach nach Umfang, mit der ausdrücklichen Option, ihn ohne mich zu machen.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Die Ausgangslage
Eine SaaS-Plattform zu bauen ist heute erstaunlich wenig Arbeit. Ein Rahmenwerk, eine Datenbank, ein Zahlungsanbieter, und nach ein paar Wochen kann sich jemand registrieren und bezahlen. Genau deshalb sieht die erste Version fast immer gut aus, und genau deshalb fällt nicht auf, dass an vier Stellen eine Entscheidung getroffen wurde, ohne dass jemand sie getroffen hat.
Die erste ist die Mandantentrennung. Eine gemeinsame Datenbank mit einer Spalte für die Kundennummer ist schnell gebaut, und sie funktioniert, solange jede Abfrage diese Spalte berücksichtigt. Die Trennung hängt dann an der Sorgfalt jedes einzelnen Entwicklers, jeden Tag, auch in dem Bericht, den jemand am Freitagnachmittag nachreicht. Die zweite ist die Abrechnung: Wer erst am Ende zählt, was ein Kunde verbraucht hat, hat keine Zahl, sondern eine Schätzung, und muss sie erklären, wenn jemand nachrechnet. Die dritte ist der Betrieb: Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung.
Die vierte fällt erst später auf und ist die unangenehmste. Irgendwann kommt ein Kunde, der so viel Last erzeugt wie alle bisherigen zusammen. Wenn sich alle Mandanten dieselbe Datenbank, dieselben Verbindungen und dieselben Hintergrundprozesse teilen, merkt das jeder andere Kunde auch. Man kann diesen Fall vorbereiten, ohne ihn heute zu bauen: Man muss nur wissen, an welcher Stelle die Plattform zuerst bricht und was das Umbauen dann kostet.
Kommt Ihnen etwas davon bekannt vor?Für wen das passt
Das Angebot richtet sich an Gründer, CTOs und Produktverantwortliche mit validiertem Problem, klarer Zielgruppe und Budget für ein dauerhaftes Produkt. Mandanten, Abrechnung, Rechte und Betrieb müssen von Anfang an tragfähig entschieden werden.
Gespräche, Pilotkunden oder ein bestehender manueller Service belegen, wer das Produkt warum nutzen und bezahlen soll.
Mandantenfähigkeit, Rollen, Billing, Datenschutz und Support sind echte Anforderungen und keine Aufgaben für irgendwann.
Produktentscheidungen bleiben bei Ihnen; Architektur und Umsetzung können gemeinsam mit Ihrem Team oder eigenständig erfolgen.
Was ich mache
Wer sind die Mandanten, was ist die Einheit, die abgerechnet wird, und welche Kundengröße soll die Plattform in zwei Jahren tragen. Diese drei Antworten entscheiden fast alles Weitere, und sie kosten einen Nachmittag. Danach steht auch, was bewusst nicht gebaut wird.
Getrennte Datenbank, getrenntes Schema oder gemeinsame Tabellen mit Row Level Security: Jede Variante hat einen Preis im Betrieb, bei den Migrationen und beim Wiederherstellen einzelner Kunden. Ich entscheide sie mit Ihnen und verankere die Trennung dort, wo sie nicht vergessen werden kann – in der Datenbank statt in jeder Abfrage.
Gezählt wird an der Stelle, an der die Nutzung entsteht, nicht am Monatsende aus einem Bericht. Der Verbrauch geht als eigene Größe zum Zahlungsanbieter, Tarifwechsel, Gutschriften und Stornos haben einen definierten Weg, und zu jeder Rechnungsposition gibt es die Datensätze, aus denen sie entstanden ist. Das ist der Unterschied zwischen einer Rechnung und einer Behauptung.
Zwei Zahlen entscheiden den Aufbau: Wie lange darf die Plattform stehen und wie viel Datenverlust ist hinnehmbar. Daraus folgen Verteilung über Zonen, Wiederherstellung auf einen Zeitpunkt und der Weg, einen einzelnen Mandanten zurückzuholen, ohne die anderen anzufassen. Im Zuschnitt entschieden und beschrieben; durchgespielt wird das im Bau danach.
Was passiert, wenn ein Mandant zehnmal so groß ist wie der Rest. Getrennte Warteschlangen und Kontingente, damit ein lauter Nachbar nicht alle bremst, ein Weg, einen einzelnen Kunden auf eigene Ressourcen zu ziehen, und eine Messung, die zeigt, welcher Mandant welche Last erzeugt. Vorbereitet heißt hier: entschieden und beschrieben, nicht heute schon gebaut.
Ein neuer Mandant entsteht auf Knopfdruck, nicht in einem Wiki-Artikel. Änderungen gehen ohne Stillstand raus, und was nur für einen Kunden gelten soll, ist ein Schalter und kein eigener Zweig im Code. Alles beschrieben als Infrastruktur in Code, damit die zweite Umgebung eine Konfiguration ist.
Bauen Sie gerade eine SaaS-Plattform, oder haben Sie eine, die nicht mehr trägt?
Schicken Sie mir, was Sie verkaufen und wie viele Kunden darauf sollen. Sie bekommen eine Einschätzung, welche der vier Entscheidungen bei Ihnen die teure ist, bevor Sie etwas beauftragen.
Ablauf
Vier Schritte. Nach dem zweiten steht das Mandantenmodell fest, und zwar begründet.
Was verkaufen Sie, an wen, und wo stehen Sie heute. Danach sage ich Ihnen, welche der vier Entscheidungen bei Ihnen offen ist – oder dass keine offen ist und Ihr heutiger Aufbau reicht. Auch das sage ich, und es ist der kürzeste Weg, mit dem wir beide leben können.
Mandantenmodell, Abrechnungseinheit, Wiederanlaufzeiten und die Zielgröße. Gemeinsam entschieden, mit den Kosten jeder Variante daneben. Das Ergebnis ist ein Papier, das Ihr Team auch ohne mich anwenden kann.
Eine Tabelle, eine Abfrage und ein Test in einem eigenen Zweig, an denen sichtbar ist, wie die Trennung im Alltag aussieht. Damit endet der Einstieg. Das lauffähige Grundgerüst als Terraform-Code in Ihrem Konto ist der Produktivbau und wird danach nach Umfang angeboten.
Eine Stunde Übergabegespräch mit den Leuten, die darauf bauen, dazu die Liste der Punkte, die beim zehnfachen Volumen zuerst brechen, nach Reihenfolge und Aufwand. Ab dann läuft es ohne mich, oder mit mir, wenn Sie das wollen.
Einstieg
Festpreis, kein Startpreis. Das Ergebnis besteht aus Entscheidungen und einem Zweig in Ihrem Repository und nicht aus einem Aufbau in Ihrer Umgebung, deshalb lässt sich die Zahl vorher nennen. Der Produktivbau danach wird nach Umfang angeboten, bevor er beginnt.
Kein Aufbau in Ihrer Umgebung, sondern die Entscheidung, die man später nicht mehr billig ändert: Nach einer Woche steht das Mandantenmodell mit seiner Begründung, ein gearbeitetes Beispiel liegt als Zweig in Ihrem Repository, die Abrechnung ist entworfen, und Sie wissen, was zuerst bricht.
Was Sie bekommen
Was Sie nicht bekommen
Das Ergebnis
Wenn die Datenbank selbst nur die Zeilen eines Mandanten herausgibt, ist eine vergessene Bedingung im Code kein Datenschutzvorfall mehr, sondern ein leeres Ergebnis. Geschenkt gibt es das nicht: Die Regel muss mit FORCE ROW LEVEL SECURITY auch für den Eigentümer der Tabelle gelten, die Anwendung braucht eine eigene Rolle ohne BYPASSRLS, und der Mandant wird mit SET LOCAL innerhalb der Transaktion gesetzt statt mit SET, sonst trägt ein Verbindungspool den Mandantenkontext der vorigen Anfrage in die nächste. Die Sorgfalt verschwindet also nicht. Sie wandert von jeder einzelnen Abfrage an eine Stelle, die einmal entschieden und einmal geprüft wird, und genau das ist der Unterschied zwischen einer Regel und einer Absicht.
Zu jeder Position gibt es die Ereignisse, aus denen sie entstanden ist. Die Frage „wie kommt diese Summe zustande" ist damit eine Abfrage und kein Nachmittag.
Wiederherstellungszeit und Datenverlust sind Zahlen, die vorher feststehen und einmal geprüft wurden. Sie können sie einem Kunden nennen, bevor er fragt, und das ist im Vertrieb mehr wert als jede Verfügbarkeitszusage ohne Beleg.
Wenn Sie wissen, an welcher Stelle die Plattform bei zehnfachem Volumen bricht und was der Umbau kostet, können Sie einen großen Vertrag annehmen und einpreisen, statt zu hoffen.
Eingesetzte Technologien
Aus der Praxis
Greenfield-Entwicklung eines zentralen, multi-tenant-fähigen gRPC-Service in Go. Ein manueller, auf mehrere Abteilungen verteilter Prozess ersetzt durch hochverfügbare Infrastruktur in EU und US, mit mehrschichtiger Cache-Architektur für unter 10ms Latenz pro Request. Die Trennung mehrerer Mandanten war dort keine Zugabe, sondern die Bedingung.
Case Study lesen
Mit wem Sie es zu tun haben
Ich bin Tim Rutte. Über 20 Jahre Softwareentwicklung, heute baue ich die Plattformen, auf denen andere ihr Produkt verkaufen. Sie sprechen mit der Person, die Ihren Code anfasst, vom ersten Gespräch bis zur Übergabe.
Häufige Fragen
Nein, das ist der günstigste Zeitpunkt. Das Mandantenmodell kostet am Anfang eine Woche und später einen Umbau bei laufendem Betrieb, mit Kunden, die davon nichts merken dürfen. Was ich nicht mache, ist Ihnen eine Plattform zu bauen, von der noch niemand weiß, ob sie jemand kauft. Genau deshalb ist der Einstieg klein geschnitten: eine Entscheidung, ein Beispiel im Code, ein Entwurf und eine Liste. Ein Repository brauchen Sie dafür nicht mitzubringen – gibt es noch keines, entsteht das Beispiel in einem neuen, das Ihnen gehört. Was danach gebaut wird, entscheiden Sie danach.
Ja, mit einem Unterschied im Ablauf: Bei einer bestehenden Plattform steht am Anfang der Befund, welche der vier Stellen tatsächlich die teure ist. Manchmal ist es die Trennung, oft die Abrechnung, und in einigen Fällen ist es keine davon, sondern eine einzelne Abfrage. Geht es um einen Bestand, den niemand mehr anfassen will, ist die Legacy-Modernisierung der passendere Einstieg, und dann sage ich das. Bricht nicht das Mandantenmodell, sondern ein einzelner Pfad unter Last, gehört das ebenfalls nicht hierher, sondern auf die Seite zu Go-Services neben PHP: Dort wird zuerst gemessen, wo die Zeit hingeht, bevor irgendetwas neu geschrieben wird.
Das hängt an drei Dingen: was Ihre Kunden vertraglich verlangen, wie viele es werden, und wie oft Sie das Schema ändern. Gemeinsame Tabellen mit Row Level Security sind im Betrieb am günstigsten und machen das Wiederherstellen eines einzelnen Kunden am schwersten. Eine Datenbank je Kunde dreht beides um und macht jede Migration zu hundert Migrationen. Getrennte Schemata liegen dazwischen. Es gibt keine allgemein richtige Antwort, nur eine begründete für Ihren Fall – und genau die ist das Ergebnis.
Weil sie bestimmt, was Sie messen müssen, und Messen kann man nur, während etwas passiert. Wer nach Nutzung abrechnet und erst am Monatsende zählt, rekonstruiert aus Protokollen, die dafür nie gedacht waren. Dazu kommt der Zahlungsanbieter: Tarifwechsel mitten im Monat, Gutschriften, Stornos und offene Beträge haben jeweils einen Weg durch Ihre Daten. Wird der später nachgezogen, betrifft er jeden Kunden, der schon eine Rechnung bekommen hat.
Zum Festpreis nicht, und auch nicht das Grundgerüst. Der Einstieg ist der Zuschnitt: entschieden, begründet und an einem Beispiel im Code gezeigt. Der Produktivbau, also das lauffähige Grundgerüst in Terraform in Ihrem Konto, ist ein eigenes Angebot und wird nach dem Zuschnitt nach Umfang angeboten. Was Ihre SaaS fachlich tut, kennen Sie ohnehin besser als ich, und dafür brauchen Sie kein Mandat, sondern Ihr eigenes Team.
Der Einstieg kostet 1.900 Euro netto zum Festpreis und umfasst das entschiedene Mandantenmodell mit seiner Begründung, ein gearbeitetes Beispiel im Code, den Entwurf für Abrechnung und Nutzungsmessung und die Bruchliste. Warum hier ein Festpreis steht und kein Startpreis: Das Ergebnis besteht aus Entscheidungen und einem Zweig in Ihrem Repository, nicht aus einem Aufbau in Ihrer Umgebung. Damit hängt der Aufwand nicht an fremden Konten, fremden Freigabeprozessen und fremden Zugängen, und die Zahl lässt sich vorher nennen. Der Produktivbau danach wird nach Umfang angeboten, bevor er beginnt, nicht in einer Nachtragsrechnung.
Für den Einstieg nicht. Mandantenmodell, Abrechnungsgröße und Bruchliste sind vom Anbieter unabhängig, und gebaut wird zu diesem Preis ohnehin nichts in Ihrer Umgebung. Beim Produktivbau danach ist AWS der günstigste Weg, weil dort Datenbank, Wiederherstellung auf einen Zeitpunkt, Verteilung über Zonen und Messung fertig vorhanden sind und konfiguriert statt gebaut werden. Wer erst noch dorthin muss, findet den Weg unter der AWS-Migration. Auf einer anderen Plattform oder im eigenen Rechenzentrum geht es ebenfalls, nur ist der Aufwand ein anderer, und deshalb wird das gesondert angeboten.
Eine Woche bis zum Ergebnis, gerechnet ab dem Tag, an dem die Zugänge stehen. Nötig sind dafür ein Lesezugriff auf ein Repository – oder ein neues, wenn es noch keines gibt – und ein bis zwei Termine mit den Leuten, die die Plattform bauen. Hängt an Ihrem Bestand ein gewachsenes System, das erst verstanden werden muss, sehen Sie das im ersten Gespräch und nicht am letzten Tag; ab etwa 200.000 Zeilen oder mehreren Anwendungen stimmen wir den Umfang vorher ab.
Weitere Leistungen
Backends für SaaS und Plattformen, die unter echter Last halten: in Go und PHP 8, event-getrieben, mit Mandantentrennung und Wiederanlauf im Entwurf.
Mehr erfahrenEinen heißen Pfad herausgelöst und als Go-Dienst lauffähig in einem eigenen Zweig, mit dem Weg zur Produktivstellung schriftlich daneben. Kein Rewrite, kein Sprachwechsel.
Mehr erfahrenVom eigenen Rechenzentrum oder aus einer anderen Cloud nach AWS, mit Kostenmodell vor dem Umzug und Rollback-Pfad für jeden Schritt.
Mehr erfahren