Alle Leistungen

SaaS-Plattformen

SaaS-Plattformen scheitern selten am Funktionsumfang. Sie scheitern an vier frühen Entscheidungen.

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.

AWS Certified Solutions Architect – ProfessionalMandantentrennung & Abrechnung6+ Mio. Nutzer im Payment-BackendFestpreis 1.900 €
Was Sie bekommen
  • Ein entschiedenes Mandantenmodell, mit Begründung und mit Preisschild im Betrieb, schriftlich in Ihrem Repository
  • Ein gearbeitetes Beispiel als Code in einem eigenen Zweig: eine Tabelle, eine Abfrage und ein Test
  • Den Entwurf für Abrechnung und Nutzungsmessung: was gezählt wird und was daraus eine Rechnung macht
  • Die Bruchliste für das zehnfache Volumen, nach Reihenfolge und mit Aufwand je Punkt
Umfang & Zusammenarbeit

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

Das Produkt ist nicht das Schwere.

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?
  • Die Trennung der Mandanten steht in der Anwendung, nicht in der Datenbank – und hält, solange niemand eine Bedingung vergisst.
  • Die Rechnung eines Kunden lässt sich nicht ohne Weiteres aus den Daten nachvollziehen.
  • Ein großer Kunde macht die Plattform für alle anderen langsam.
  • Ein neuer Kunde wird von Hand eingerichtet, und nur zwei Leute wissen wie.
  • Ein Backup gibt es, zurückgespielt hat es noch nie jemand.
  • Jeder Rollout ist ein Termin am Abend, weil währenddessen nichts geht.

Für wen das passt

Für Produktverantwortliche, deren SaaS-Idee bereits einen Markt – und jetzt technische Konsequenzen hat.

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.

01

Das Problem ist validiert.

Gespräche, Pilotkunden oder ein bestehender manueller Service belegen, wer das Produkt warum nutzen und bezahlen soll.

02

Das Produkt braucht mehr als einen Prototyp.

Mandantenfähigkeit, Rollen, Billing, Datenschutz und Support sind echte Anforderungen und keine Aufgaben für irgendwann.

03

Sie wollen Verantwortung klar verteilen.

Produktentscheidungen bleiben bei Ihnen; Architektur und Umsetzung können gemeinsam mit Ihrem Team oder eigenständig erfolgen.

Was ich mache

Was dabei entsteht

01

Zuschnitt vor dem Bau

MandantenbegriffAbrechnungseinheitZielgröße

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.

02

Mandantentrennung, die nicht an Sorgfalt hängt

Multi-TenancyRow Level SecurityIsolationsstufen

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.

03

Abrechnung und Nutzungsmessung

StripeMeteringTarife & Kontingente

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.

04

Betrieb mit Wiederanlauf

Multi-AZPoint-in-Time RecoveryWiederanlaufzeiten

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.

05

Der zehnte Kunde

KontingenteLastverteilungAmazon Aurora

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.

06

Ausrollen und neue Kunden

TerraformBlue-GreenFeature Flags

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

Wie das abläuft

Vier Schritte. Nach dem zweiten steht das Mandantenmodell fest, und zwar begründet.

SCHRITT 01

Gespräch, 30 Minuten

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.

SCHRITT 02

Die vier Entscheidungen

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.

SCHRITT 03

Ein gearbeitetes Beispiel im Repository

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.

SCHRITT 04

Übergabe

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

Mandantenmodell entschieden. Festpreis 1.900 €

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

  • Das entschiedene Mandantenmodell mit seiner Begründung: geteilte Datenbank mit Mandantenspalte, gemeinsame Tabellen mit Row Level Security, getrennte Schemata oder getrennte Datenbanken, samt den Abwägungen dahinter, schriftlich in Ihrem Repository
  • Die beiden Zahlen des Betriebs als Entscheidung: zulässige Wiederanlaufzeit und hinnehmbarer Datenverlust, dazu die Zielgröße, die die Plattform in zwei Jahren tragen soll
  • Ein gearbeitetes Beispiel als Code in einem eigenen Zweig: eine Tabelle, eine Abfrage und ein Test, an denen sichtbar ist, wie die Trennung im Alltag aussieht. Kein Gutachten, ein Anfang
  • Der Entwurf für Abrechnung und Nutzungsmessung: was gezählt wird, wo es gezählt wird, und was daraus eine Rechnung macht
  • Die Bruchliste: was zuerst bricht, wenn ein Kunde so groß wird wie alle anderen zusammen, mit Aufwandsschätzung je Punkt und in Reihenfolge
  • Eine Stunde Übergabegespräch mit den Leuten, die darauf bauen, Aufzeichnung auf Wunsch

Was Sie nicht bekommen

  • Kein lauffähiges Grundgerüst als Terraform-Code in Ihrem Konto. Das ist der Produktivbau, ein eigenes Angebot, und es wird nach dem Zuschnitt gemacht, wenn Sie es wollen
  • Nichts, was in Ihrer Umgebung aufgebaut oder produktiv gestellt wird: kein Netz, keine Datenbank, kein Ausrollweg und keine Wiederanlaufprobe. Was hier entsteht, steht im Repository, nicht im Betrieb
  • Kein fertiges Produkt. Es entsteht der Zuschnitt, keine Fachlogik und kein verkaufsfertiger Dienst
  • Keine Oberfläche, kein Entwurf der Gestaltung und keine Registrierungsstrecke
  • Keine Anbindung eines Zahlungsanbieters. Die Abrechnung wird entworfen, angebunden wird sie im Bau danach
  • Keine Migration bestehender Kunden und Daten in das neue Modell. Das hängt an Ihrem Bestand und ist ein eigenes Vorhaben
  • Kein zweites Mandantenmodell zum Vergleich gebaut. Entschieden wird eines, begründet werden die Alternativen
  • Keine rechtliche oder datenschutzrechtliche Bewertung und keine Zertifizierung nach ISO 27001 oder SOC 2. Was die Architektur dafür beitragen kann, steht im Papier, entscheidet das Ihr Datenschutzbeauftragter
  • Keine laufende Betreuung ohne eigene Vereinbarung
  • Lesezugriff auf ein Repository genügt. Der Beispielzweig entsteht daneben, Ihr Hauptzweig bleibt unangetastet
  • Gibt es noch kein Repository, weil noch keine Zeile Code geschrieben ist, entsteht das Beispiel in einem neuen, das Ihnen gehört
  • Das Projekt lässt sich lokal bauen und starten, mit Abhängigkeiten, Fixtures und Datenbank – sonst läuft der Test nicht. Geht das nicht in vertretbarer Zeit, entsteht das Beispiel in einem eigenständigen Beispielprojekt
  • Ab etwa 200.000 Zeilen oder mehreren Anwendungen wird der Umfang vorher abgestimmt
  • Ein bis zwei Termine mit den Leuten, die die Plattform bauen
  • Eine Person, die über Preismodell und Mandantenmodell entscheiden darf. Ohne diese Entscheidung entsteht kein Ergebnis, sondern eine Liste von Varianten
  • Kein Zugang zu Ihrer AWS-Umgebung nötig. Genau deshalb steht hier ein Festpreis
  • Der Festpreis gilt unabhängig davon, wie lange die Arbeit dauert
  • Ergebnis in einer Woche, gerechnet ab dem Tag, an dem die Zugänge stehen
  • Was entsteht, liegt in Ihrem Repository und gehört Ihnen
  • Preis netto, zuzüglich Umsatzsteuer
  • Sie sind zu nichts weiter verpflichtet. Manche Teams bauen danach allein weiter, und dafür ist das Papier gemacht

Das Ergebnis

Was danach anders ist

Die Trennung hält ohne Disziplin

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.

Rechnungen, die eine Rückfrage überstehen

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.

Ein Ausfall ist ein Ablauf

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.

Der große Kunde ist ein Angebot, kein Risiko

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

Womit ich arbeite

Sprachen
  • Golang
  • PHP 8
  • TypeScript
Schnittstellen
  • REST
  • gRPC
  • Webhooks
Mandantentrennung
  • Multi-Tenancy
  • Row Level Security
  • Feature Flags
Daten
  • PostgreSQL
  • Amazon Aurora
  • Redis
Abrechnung
  • Stripe
  • Stripe Billing
  • Metering
Laufzeit
  • Amazon ECS
  • AWS Lambda
  • API Gateway
Ausrollen
  • Terraform
  • Blue-Green
  • GitHub Actions
Betrieb
  • OpenTelemetry
  • CloudWatch
  • Multi-AZ

Aus der Praxis

Tim Rutte, Cloud & Software Architect

Mit wem Sie es zu tun haben

Direkt mit mir als Freelancer. Keine Agentur dazwischen.

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.

  • 20+Jahre Softwareentwicklung
  • 50+erfolgreiche Projekte
  • 2003seit diesem Jahr remote im Einsatz
Mehr über mich

Häufige Fragen

Häufige Fragen zu SaaS-Plattformen

Wir haben noch keine Zeile Code. Ist das zu früh?

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.

Wir haben schon eine SaaS-Plattform, sie trägt nur nicht mehr. Sind wir hier richtig?

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.

Eine Datenbank für alle Mandanten oder eine je Kunde?

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.

Warum ist die Abrechnung eine Architekturfrage und keine Sache für später?

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.

Bauen Sie uns das ganze Produkt?

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.

Was kostet der Aufbau einer SaaS-Plattform?

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.

Muss das auf AWS laufen?

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.

Wie lange dauert es wirklich?

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

Womit ich sonst helfe.