Wir entwickeln seit Januar 2026 mehrere eigene SaaS-Produkte auf einer gemeinsamen .NET-Plattform und verantworten dafür Architektur, Umsetzung und Betrieb. Im Mittelpunkt stehen eine gemeinsame technische Basis, wiederverwendbare Bausteine und der Betrieb in Azure, damit unterschiedliche Produktideen auf derselben Plattform umgesetzt werden können. Dazu gehören Fachfunktionen für Threat Intelligence, Prüfprozesse rund um GitHub-Profile und W3C Verifiable Credentials sowie Gameserver-Hosting mit Abrechnung.
Ausgangslage
Bei diesem Vorhaben handelt es sich um ein eigenes Projekt von ballmüller solutions. Ausgangspunkt war die Aufgabe, mehrere eigene SaaS-Produkte nicht als isolierte Einzellösungen, sondern auf einer gemeinsamen Plattform zu entwickeln und zu betreiben. Dafür mussten wiederkehrende Themen wie Authentifizierung, Wallet, Abrechnung, Ereignisverarbeitung, Marketing-Automatisierung, Analytics und der Betrieb in Azure so aufgebaut werden, dass sie produktübergreifend nutzbar sind.
Zugleich sollten sehr unterschiedliche Fachdomänen auf derselben Basis abgebildet werden: KI-Köder-Personas für Threat Intelligence, Prüfungen von GitHub-Profilen mit Ausstellung von W3C Verifiable Credentials sowie Gameserver-Hosting mit Abrechnung und weiteren Funktionen.
Lösung
Wir haben die IT-Architektur, die Umsetzung und den Betrieb mehrerer eigener SaaS-Produkte auf einer gemeinsamen .NET-Plattform aufgebaut. Dazu gehören rund 57 eigene NuGet-Pakete als wiederverwendbare Bausteine. NuGet-Pakete sind interne Softwarebausteine, mit denen sich gemeinsame Funktionen konsistent in mehreren Anwendungen nutzen lassen.
Auf der Plattform haben wir die Fachlösungen umgesetzt und zentrale Dienste integriert: Authentifizierung mit Entra ID und Passkeys, Wallet und Event Sourcing, Marketing-Automatisierung mit KI, Analytics, einen gemeinsamen Azure Front Door sowie Infrastruktur als Code mit Bicep. Infrastruktur als Code bedeutet, dass Cloud-Ressourcen in beschreibbaren Vorlagen definiert und nachvollziehbar bereitgestellt werden. Das Projekt läuft seit Januar 2026 bis heute und wird von 1 Person umgesetzt. Teile der Umsetzung umfassen Webentwicklung, Datenbankentwicklung und den Betrieb in Azure.
Ergebnis
Geliefert wurde eine gemeinsame Plattform für mehrere eigene SaaS-Produkte sowie deren Betrieb in Azure. Auf dieser Basis entstanden Active Defense, Acquispect und EphemeralHost mit ihren jeweils unterschiedlichen fachlichen Anforderungen.
Der Projektzeitraum reicht von Januar 2026 bis heute. Die Laufzeit ist noch offen, da das Vorhaben weiterläuft. Das Projekt wird mit einer Teamgröße von 1 umgesetzt.
Technik
Zum Einsatz kommen .NET 10 und .NET Aspire als Grundlage der Plattform. Microsoft Orleans, Eventuous und FastEndpoints werden für die Anwendungsarchitektur und die Umsetzung von Fachlogik eingesetzt. Blazor WebAssembly und Blazor Server dienen für browserbasierte Oberflächen.
Für den Betrieb nutzen wir Azure Container Apps, Azure SQL, Azure Front Door und Key Vault. Azure SQL ist ein verwalteter Datenbankdienst in der Microsoft Cloud. Key Vault dient zur geschützten Ablage sensibler Werte und Schlüssel. Bicep wird für Infrastruktur als Code verwendet, Azure DevOps für den Entwicklungs- und Bereitstellungsprozess.
Darüber hinaus kommen Azure OpenAI für KI-Funktionen, Stripe für die Abrechnung sowie Entra ID und External ID für Authentifizierung und Identitätsverwaltung zum Einsatz.
Warum sich eine SaaS-Plattform Entwicklung oft lohnt
Eine SaaS-Plattform Entwicklung ist besonders dann sinnvoll, wenn mehrere Produkte oder Produktvarianten auf gemeinsamen Grundlagen aufbauen sollen. Statt jedes System separat zu planen, zu entwickeln und zu betreiben, wird eine technische Basis geschaffen, auf der wiederkehrende Funktionen nur einmal aufgebaut werden. Dazu zählen typischerweise Anmeldung, Benutzer- und Rechteverwaltung, Abrechnung, Mandantenfähigkeit, Protokollierung, Auswertungen, Benachrichtigungen und der Betrieb in der Cloud.
Der Vorteil dieses Ansatzes liegt weniger in einer einzelnen Funktion als in der Struktur des Gesamtvorhabens. Wenn gemeinsame Bausteine sauber getrennt sind, lassen sich neue Produkte konsistenter umsetzen. Entscheidungen zu Sicherheit, Deployment, Datenhaltung oder Monitoring werden dann nicht für jedes Teilprodukt neu getroffen, sondern auf einer übergreifenden Ebene vorbereitet. Das reduziert Abstimmungsaufwand und erleichtert die Weiterentwicklung.
Für solche Vorhaben ist eine klare Architektur entscheidend. Architektur meint die Aufteilung eines Systems in fachliche und technische Bausteine sowie deren Zusammenspiel. Gerade bei Plattformen entstehen sonst schnell versteckte Abhängigkeiten: Eine Änderung im Identitätsmanagement wirkt sich auf Oberflächen, Schnittstellen und Abrechnung aus; eine neue Datenquelle verändert Analytics und Berechtigungen; ein zusätzlicher Mandant stellt Anforderungen an Isolation und Supportprozesse.
Typisch ist deshalb ein Aufbau mit gemeinsamen Plattformdiensten und davon getrennten Fachmodulen. Plattformdienste sind technische Grundfunktionen, die mehrere Anwendungen gemeinsam nutzen. Fachmodule bilden dagegen die Logik eines konkreten Produkts ab. Diese Trennung hilft, Verantwortlichkeiten sauber zu halten und Änderungen planbarer zu machen.
Auch der Betrieb sollte früh mitgedacht werden. Eine Plattform ist nicht nur eine Entwicklungsfrage, sondern auch ein Betriebsmodell. Dazu gehören reproduzierbare Umgebungen, nachvollziehbare Releases, Schutz sensibler Daten, zentrale Protokolle und ein Konzept für Vorfälle. Reproduzierbar bedeutet, dass eine Umgebung immer wieder mit denselben Einstellungen bereitgestellt werden kann.
Wer ein ähnliches Vorhaben plant, sollte deshalb zuerst die Gemeinsamkeiten der Produkte identifizieren: Was ist wirklich plattformfähig, was bleibt produktspezifisch, welche Schnittstellen werden dauerhaft benötigt und welche Betriebsaufgaben müssen von Anfang an verlässlich abgedeckt sein. Für eine erste Einordnung des Umfangs helfen der Kostenrechner oder ein Projekt-Check.
So wird eine SaaS-Plattformentwicklung sinnvoll aufgebaut
Bei einer SaaS-Plattformentwicklung empfiehlt sich ein Vorgehen in klar getrennten Schritten. Zuerst werden fachliche Ziele, Zielgruppen, Produktgrenzen und gemeinsame Plattformthemen geklärt. Dabei geht es nicht nur um Funktionen, sondern auch um Rollen, Mandanten, Datenflüsse, Abrechnung, Schnittstellen und den späteren Betrieb. Mandantenfähigkeit bedeutet, dass mehrere Kunden oder Organisationen dasselbe System nutzen können, ohne ihre Daten zu vermischen.
Im nächsten Schritt entsteht ein fachliches und technisches Konzept. Hier werden Kernprozesse beschrieben, die Zuständigkeiten von Plattform und Fachmodulen abgegrenzt und die wichtigsten Datenobjekte festgelegt. Ebenso wird entschieden, welche Oberflächen erforderlich sind, welche Systeme angebunden werden und wie Authentifizierung, Berechtigungen und Protokollierung aufgebaut sein sollen. Protokollierung bedeutet, dass wichtige Vorgänge nachvollziehbar aufgezeichnet werden.
Danach folgt die Umsetzung in sinnvollen Ausbaustufen. Gerade bei Plattformprojekten ist es hilfreich, zuerst die Grundlagen zu schaffen, auf denen spätere Produktfunktionen aufsetzen. Dazu gehören typischerweise Identitätsmanagement, Bereitstellung in der Cloud, gemeinsame Daten- und Ereignismodelle, Grundstrukturen für APIs sowie ein belastbarer Entwicklungsprozess. APIs sind definierte Schnittstellen, über die Systeme Daten und Funktionen austauschen.
Wichtig ist eine regelmäßige fachliche Rückkopplung. Plattformprojekte scheitern oft nicht an fehlender Technik, sondern an unklaren Entscheidungen: Welche Funktion gehört in die gemeinsame Basis, welche nur in ein Produkt? Wie weit wird Standardisierung sinnvoll, wo würde sie ein Fachthema unnötig einschränken? Diese Fragen sollten laufend entschieden und dokumentiert werden.
Vor dem Livegang braucht es Qualitätssicherung und Betriebsprüfung. Dazu gehören Tests der Kernprozesse, Prüfungen der Berechtigungen, Beobachtbarkeit im laufenden Betrieb und klare Abläufe für Fehler, Änderungen und Support. Beobachtbarkeit bedeutet, dass das Verhalten eines Systems über Protokolle, Metriken und Meldungen verstanden werden kann.
In unserer Arbeit strukturieren wir solche Vorhaben typischerweise in Kennenlernen, Konzept und Design, Entwicklung, Qualitätssicherung und Livegang sowie anschließenden Support und Weiterentwicklung. Wer ein ähnliches Projekt vorbereiten möchte, kann ein unverbindliches Erstgespräch nutzen, um Ziele, Risiken und sinnvolle Zuschnitte früh zu sortieren.
Typische Stolpersteine bei Plattformen, Daten und Betrieb
Bei Projekten dieser Art liegen die größten Risiken oft an den Übergängen zwischen Fachlichkeit, Plattform und Betrieb. Ein häufiger Stolperstein ist eine zu frühe Verallgemeinerung. Wenn zu Beginn jede denkbare Produktvariante berücksichtigt werden soll, entstehen leicht zu abstrakte Bausteine, die schwer verständlich und teuer in der Pflege werden. Umgekehrt ist auch ein zu enger Zuschnitt problematisch, weil dann dieselben Funktionen mehrfach in verschiedenen Produkten nachgebaut werden.
Besonders sensibel sind Identitäten, Rechte und Mandanten. Schon kleine Unklarheiten in Rollenmodellen oder Zugriffsregeln führen später zu hohem Korrekturaufwand. Rollenmodelle beschreiben, welche Nutzergruppen welche Funktionen sehen oder ausführen dürfen. Deshalb sollten diese Regeln früh als fachliche Entscheidungen dokumentiert und nicht nur in der Technik implizit umgesetzt werden.
Ein weiterer kritischer Punkt sind Schnittstellen und Datenflüsse. Werden externe Systeme angebunden, müssen Formate, Fehlerfälle, Zeitverhalten und Verantwortlichkeiten sauber geklärt sein. Schnittstellen wirken im Projekt oft zunächst einfach, verursachen aber später hohen Aufwand, wenn Rückmeldungen fehlen, Daten unvollständig sind oder sich externe Vorgaben ändern. Besonders bei ereignisgetriebenen Architekturen ist wichtig, welche Informationen verbindlich gespeichert werden und wie Korrekturen nachvollziehbar bleiben. Ereignisgetrieben heißt, dass Änderungen und Vorgänge als einzelne Ereignisse verarbeitet und weitergegeben werden.
Auch der laufende Betrieb braucht klare Entscheidungen. Dazu gehören Deployment, Geheimnisverwaltung, Monitoring, Incident-Prozesse und Datensicherung. Deployment ist die kontrollierte Bereitstellung neuer Softwarestände. Geheimnisverwaltung meint den geschützten Umgang mit Zugangsdaten, Schlüsseln und anderen sensiblen Informationen. Ohne diese Grundlagen wird aus einer technisch funktionierenden Plattform schnell ein organisatorisch schwer beherrschbares System.
Nicht zuletzt spielen rechtliche und organisatorische Fragen eine Rolle, etwa Datenschutz, Aufbewahrung, Nachvollziehbarkeit von Entscheidungen oder Anforderungen an Barrierefreiheit. Diese Themen sollten früh benannt und mit den zuständigen Stellen geprüft werden; eine rechtliche Bewertung sollte durch Juristen oder den Datenschutzbeauftragten erfolgen.
Für die Praxis heißt das: Eine gute Plattform braucht nicht nur gute Technik, sondern klare fachliche Grenzen, definierte Betriebsverantwortung und saubere Entscheidungen zu Daten, Sicherheit und Schnittstellen. Genau an diesen Punkten lohnt sich zu Beginn ein nüchterner Architektur- und Projektabgleich.
Häufige Fragen
Welche Faktoren treiben bei einer SaaS-Plattform die Kosten?
Die Kosten hängen vor allem davon ab, wie viel gemeinsame Plattformlogik aufgebaut werden soll und wie unterschiedlich die darauf aufsetzenden Produkte sind. Relevant sind typischerweise Identitätsmanagement, Mandantenfähigkeit, Abrechnung, Schnittstellen, Datenmodell, Oberflächen, Cloud-Betrieb und Qualitätssicherung. Zusätzlichen Aufwand verursachen Anforderungen an Nachvollziehbarkeit, Protokollierung und Sicherheit. Für eine grobe Einordnung eignet sich der Kostenrechner oder ein Projekt-Check auf Basis einer vorhandenen Beschreibung.
Wovon hängt die Dauer eines solchen Projekts ab?
Die Dauer wird vor allem durch den Zuschnitt des ersten Ausbaustands bestimmt. Entscheidend ist, ob zunächst nur ein tragfähiger Plattformkern entstehen soll oder ob mehrere Fachmodule parallel aufgebaut werden. Einfluss haben außerdem Abstimmungswege, verfügbare Entscheidungen, externe Schnittstellen und die Tiefe der Qualitätssicherung. Sinnvoll ist meist ein Vorgehen in Ausbaustufen, damit Grundlagen, Fachlogik und Betrieb nicht ungeordnet nebeneinander entstehen.
Sollte man mit einem Produkt starten oder gleich die ganze Plattform planen?
In solchen Projekten ist meist ein Mittelweg sinnvoll. Die Plattform sollte von Beginn an bewusst entworfen werden, aber nicht als abstraktes Konstrukt ohne konkrete Fachanforderung entstehen. Bewährt hat sich, die gemeinsame Basis an einem klar abgegrenzten Produkt oder Kernprozess aufzubauen. So bleiben Architekturentscheidungen praxisnah, während zentrale Themen wie Authentifizierung, Rollen, Datenhaltung und Betrieb trotzdem von Anfang an sauber angelegt werden.
Welche Risiken werden bei SaaS-Projekten häufig unterschätzt?
Häufig unterschätzt werden Rechtekonzepte, Datenflüsse über Systemgrenzen hinweg und der Aufwand für den Betrieb. Auch wiederkehrende Themen wie Abrechnung, Benachrichtigungen, Protokollierung und Support wirken anfangs kleiner, als sie später sind. Kritisch sind zudem Änderungen an Schnittstellen externer Dienste und unklare Verantwortlichkeiten im Fehlerfall. Deshalb sollten fachliche Zuständigkeiten, technische Grenzen und Betriebsprozesse früh dokumentiert und regelmäßig überprüft werden.
Was muss der laufende Betrieb einer solchen Plattform leisten?
Der Betrieb muss mehr abdecken als das reine Hosting. Er umfasst typischerweise Bereitstellungen, Überwachung, Fehleranalyse, Schutz sensibler Informationen, Datensicherung und nachvollziehbare Änderungen. Überwachung bedeutet, dass Ausfälle, Fehlverhalten und Auffälligkeiten früh erkannt werden. Wichtig ist außerdem, wie neue Funktionen ausgerollt, Vorfälle bearbeitet und Abhängigkeiten zu Cloud-Diensten oder Drittanbietern beobachtet werden. Für produktive Plattformen sollte dieser Teil von Anfang an mitgeplant werden.
