Eine Plattform, die viele Kunden trägt
Mandantentrennung, Teams und Rechte, wiederkehrende Abrechnung: Die Entscheidungen am Anfang bestimmen, wie weit eine SaaS-Plattform später trägt. Genau dort beginnt die Arbeit.
Die Weichen stehen am Anfang
Eine SaaS-Plattform ist nicht einfach eine Anwendung, die mehrere Kunden bedient. Der Unterschied steckt in Entscheidungen, die ganz am Anfang fallen und später kaum noch zu ändern sind: Wie werden die Daten der Kunden voneinander getrennt? Ist der Kunde eine Person oder ein Unternehmen mit mehreren Beteiligten? Was passiert, wenn jemand den Tarif mitten im Monat wechselt oder kündigt? Wer diese Fragen früh beantwortet, spart sich später Umbauten an der Stelle, an der alles zusammenhängt.
Die wichtigste davon ist die Trennung der Mandanten. Üblich sind zwei Wege: Alle Kunden liegen in einer Datenbank und jeder Datensatz ist einem Mandanten zugeordnet, oder jeder Kunde bekommt eine eigene Datenbank. Der erste Weg ist günstiger im Betrieb und für die meisten Plattformen richtig; der zweite lohnt sich, wenn Kunden getrennte Sicherungen, eigene Speicherorte oder besondere Nachweise verlangen. Diese Wahl fällt im Konzept, nicht während der Entwicklung, und sie wird gezielt geprüft: Dass niemand Daten sieht, die ihm nicht gehören, ist die einzige Eigenschaft, bei der es keinen Kompromiss gibt.
Genauso früh gehören Teams und Rechte geklärt. In den meisten Plattformen ist der zahlende Kunde ein Unternehmen: Jemand lädt Kolleginnen ein, verteilt Rollen, sieht Rechnungen, andere nur ihre eigenen Vorgänge. Nachträglich von Einzelnutzern auf Teams umzustellen berührt fast jede Abfrage in der Anwendung. Umgesetzt wird das mit den etablierten Bausteinen aus dem Laravel-Umfeld statt mit Eigenentwicklungen, weil dort die Sonderfälle schon durchdacht sind.
Bei der Abrechnung übernimmt ein etablierter Zahlungsanbieter die Zahlungsdaten, sodass sie gar nicht erst auf dem eigenen Server liegen. Wiederkehrende Zahlungen, Testphasen und Tarifwechsel laufen darüber, dazu ein Bereich, in dem Kunden ihre Angaben selbst ändern, Rechnungen laden und kündigen können. Aufwand macht dabei selten die Zahlung selbst, sondern das Drumherum: anteilige Berechnung beim Wechsel, gescheiterte Abbuchungen, Sperren und Wiederfreischalten. Diese Fälle werden vorher durchgesprochen, weil sie im Betrieb sonst als Support-Aufwand zurückkommen.
Aufgebaut wird in Stufen: erst Grundgerüst mit Mandantentrennung, dann die Funktion, für die Kunden zahlen, dann die Abrechnung, dann der Ausbau. Wer umgekehrt beginnt, hat früh eine Plattform, die kassieren kann, aber noch nichts leistet. Für die interne Verwaltung kommt meist Filament zum Einsatz, und sobald Kunden die Plattform mit eigenen Systemen verbinden wollen, kommt eine dokumentierte Schnittstelle dazu, die dann selbst zum Produktmerkmal wird.
Die Zusammenarbeit läuft standardmäßig zu 100 % remote und damit ortsunabhängig, direkt mit Gründern und Produktverantwortlichen, als Verstärkung für Agenturen und über IT-Vermittler. Code geht über Git, Zwischenstände stehen auf einer Testumgebung bereit. Weil auf einer Plattform Personendaten der Endkunden verarbeitet werden, gehört ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO zum Auftrag. Gearbeitet wird aus dem eigenen Büro im kontorworx-Coworking-Space in Rheine, persönliche Termine vor Ort sind nach Absprache möglich.
Aktuelle Verfügbarkeit · Eingeschränkt
Freie Kapazität ab 01.09.2026
Antwort innerhalb von 2-5 Werktagen je nach Projektgröße.
Wann lohnt sich eine eigene Plattform?
Aus einem Dienst soll ein Produkt werden
Was heute als Dienstleistung erbracht wird, soll künftig als Software mehrfach verkauft werden. Der Weg dahin ist weniger eine Frage der Technik als der Trennung: Was ist am Ablauf allgemein und was war bisher Einzelfall?
Mehrere Kunden auf einer Plattform
Verschiedene Unternehmen sollen dieselbe Anwendung nutzen, ohne die Daten der anderen zu sehen. Diese Trennung ist die Grundsatzentscheidung überhaupt und lässt sich später nur mit erheblichem Aufwand ändern.
Wiederkehrende Abrechnung soll automatisch laufen
Monatliche oder jährliche Zahlung, Testphasen, Auf- und Abstufungen, Rechnungen und Mahnungen: Sobald das von Hand läuft, kostet jeder neue Kunde Verwaltungszeit statt Deckungsbeitrag.
Teams statt Einzelnutzer
Kunden sind keine einzelnen Personen, sondern Unternehmen mit mehreren Beteiligten und unterschiedlichen Rechten. Einladungen, Rollen und der Wechsel zwischen Bereichen gehören dann früh in die Grundlage.
Der Prototyp trägt nicht mehr
Die erste Fassung wurde schnell gebaut und funktioniert für zehn Kunden. Mit hundert zeigt sich, wo die Trennung der Daten, die Rechte oder die Abrechnung an ihre Grenzen kommen. Was davon umgebaut werden muss, klärt eine Bestandsaufnahme.
Der erste größere Kunde stellt Anforderungen
Eigene Anmeldung über das Firmenkonto, Datenhaltung in Europa, Ausfuhr aller Daten auf Wunsch, Nachweise zur Sicherheit: Solche Anforderungen kommen selten allein und verändern die Anforderungen an die Plattform spürbar.
Die Plattform braucht Schnittstellen
Kunden möchten die Plattform mit ihren eigenen Systemen verbinden. Eine dokumentierte Schnittstelle wird damit selbst zum Produktmerkmal, nicht zum Nebenprodukt.
Bestehende Plattform soll weiterentwickelt werden
Die Plattform läuft, aber die Entwicklung stockt oder das bisherige Team ist nicht mehr verfügbar. Auch fremder Code wird übernommen: erst die Analyse des Bestands, dann Weiterentwicklung auf dieser Grundlage.
Wie die Plattform entsteht
Die Reihenfolge ist bewusst so gewählt: Was alles trägt, entsteht zuerst, die Abrechnung später. Wie viele Ausbaustufen folgen, entscheidet der Betrieb. Vertragsbasis ist ein Dienstvertrag mit Abrechnung nach Aufwand, vorab gibt es eine ehrliche Aufwandsschätzung.
-
1
1. Konzept und Grundsatzentscheidungen
Wie werden Kunden voneinander getrennt, was ist ein Konto und was ein Team, wie sehen die Tarife aus und was passiert beim Wechsel zwischen ihnen. Diese Entscheidungen prägen die Plattform über Jahre und gehören deshalb an den Anfang, nicht in die zweite Ausbaustufe.
-
2
2. Grundgerüst mit Mandantentrennung
Anmeldung, Teams, Rollen und Rechte, dazu die Trennung der Daten zwischen den Kunden. Alles Weitere baut darauf auf, deshalb entsteht dieser Teil zuerst und wird gezielt geprüft: Niemand darf Daten sehen, die ihm nicht gehören.
-
3
3. Der Kern des Produkts
Die Funktion, für die Kunden zahlen, vollständig umgesetzt und benutzbar. Ohne Abrechnung, ohne Randfunktionen, dafür so weit, dass echte Nutzer damit arbeiten und Rückmeldung geben können.
-
4
4. Abrechnung und Selbstverwaltung
Anbindung des Zahlungsanbieters, Tarife, Testphasen, Auf- und Abstufungen, Rechnungen. Dazu ein Bereich, in dem Kunden Zahlungsmittel ändern, Rechnungen laden und kündigen können, ohne dass jemand aus dem Team eingreifen muss.
-
5
5. Start und Ausbau
Einrichtung der Umgebung, Überwachung, Sicherungen und Übergabe. Danach wächst die Plattform in Stufen weiter, entlang dem, was sich im Betrieb tatsächlich zeigt.
Fragen zu SaaS-Plattformen
Was kostet die Entwicklung einer SaaS-Plattform?
Wie werden die Kunden voneinander getrennt?
Wie läuft die Abrechnung?
Wie werden Teams und Rechte gelöst?
Mit welchem Stack wird gebaut?
Wie lange dauert es bis zur ersten Fassung?
Wer betreut die Plattform später?
Was passiert, wenn du ausfällst oder später nicht verfügbar bist?
Auch interessant
Tagessätze und Wartungspakete stehen offen.
Für Laravel SaaS-Plattformen gilt derselbe Satz wie für jede andere Aufgabe: 760 bis 1.080 € pro Tag netto (95 bis 135 € pro Stunde), je nach Laufzeit und Dringlichkeit, Wartungspakete ab 349 € pro Monat. Alle Stufen im Detail auf der Laravel-Seite. Was eine konkrete Aufgabe kostet, ergibt sich aus der Aufwandsschätzung nach dem Erstgespräch.
Neue Plattform oder bestehende weiterentwickeln?
Eine kurze Beschreibung der Idee und der Zielkunden genügt. Antwort mit erster Einschätzung innerhalb von 2-5 Werktagen.
Tagessätze 760-1.080 € netto · Antwort in 2-5 Werktagen · Direktkontakt