SaaS-Entwicklung

In der Praxis nein. Die Mandantentrennung berührt jede Tabelle, jede Abfrage und jede Rechteprüfung; sie nachzurüsten heißt, den Großteil des Systems neu zu schreiben. Deshalb wird die Mandantenkennung im ersten Datenmodell definiert und auf Datenbankebene erzwungen. Selbst bei Start mit einem einzigen Kunden ist der Mehraufwand gering — das Nachrüsten kann so viel kosten wie das Projekt.

Preise und Tarife werden nicht fest codiert, sondern als fachlich änderbare Datensätze gehalten. Eine Preisänderung, ein neuer Tarif oder eine nutzungsbasierte Position braucht dann kein Release. Testphasen, Up- und Downgrades sowie anteilige Berechnung werden von Anfang an definiert, und zwischen Zahlungsdienstleister und Rechnungsdatensatz wird eine Abstimmungsregel festgelegt.

Am häufigsten sind Single Sign-on, rollenbasierte Rechte und Audit-Logging. Unternehmenskunden fordern meist alle drei bereits im ersten Vertrag, und keines lässt sich nachträglich in die Architektur einbauen. Dicht dahinter folgen Aufbewahrungsfristen, Exportrechte und die Frage, wo die Daten liegen. Soll das Produkt an Unternehmen verkauft werden, gehören diese Punkte in Release eins.

Beides ist möglich, und die Wahl steht im Vertrag. Läuft das Produkt auf Ihrer Infrastruktur und übernimmt Ihr Team, übergeben wir Quellcode, Deployment-Pipeline, Monitoring-Konfiguration und ein Runbook. Sollen wir den Betrieb weiterführen, werden Service Level, Reaktionszeiten und Rufbereitschaft als eigener Scope definiert.