- SaaS-Integrationen sollen es Entwicklerinnen und Entwicklern ermöglichen, sich nur auf das Produkt zu konzentrieren, aber in der Praxis gibt es jedes Mal fünf versteckte Kosten (Steuern)
- Schon vor der Einführung und in jeder Phase von Entdeckung, Anmeldung, Integration, lokaler Entwicklung und Betrieb entstehen fortlaufend Zeitaufwand, Komplexität und mentale Belastung
- Wer statt einzelner SaaS-Dienste eine integrierte Plattform (Cloudflare, Supabase usw.) wählt, kann diese wiederkehrenden Kosten und diese Komplexität stark reduzieren
- Vendor Lock-in ist eine unvermeidliche Realität; statt viele Services zu mischen, ist es am besten, den Entwicklungsfluss (Flow) auf einer integrierten Plattform zu bewahren
- Am Ende ist das Wichtigste nicht das Framework oder der Service selbst, sondern die Software, die ich bauen will
SaaS ist nur Vendor Lock-in mit besserem Branding
- Entwicklerinnen und Entwickler hören oft „Konzentrier dich nur auf die Produktentwicklung“, doch in der Praxis bringt die Einführung von SaaS-Anbietern für Dinge wie Auth, Queues, Dateispeicher oder Bildoptimierung verschiedene Belastungen mit sich
- Es gibt nicht nur finanzielle Kosten, sondern auch Zeitverlust, Reibung und mentale Ermüdung.
1. Entdeckungssteuer (Discovery Tax)
- Bevor ein SaaS-Dienst eingeführt wird, muss man zunächst verstehen, welche Funktion und welchen Wert er tatsächlich verkauft
- Man muss Details bewerten wie den Umfang der Problemlösung, die Kompatibilität mit dem bestehenden Stack, ein im Verhältnis zur Größe vernünftiges Preismodell, die Klarheit der Dokumentation und eigenwillige Implementierungsweisen
- Dieser Rechercheprozess lässt sich kaum aus früheren Erfahrungen teilen oder wiederholen; ein großer Teil davon ist subjektive Entscheidung
- Man trägt die Last, selbst beurteilen zu müssen, ob die Marketingbotschaft zu den eigenen Anforderungen passt und ob der Dienst tatsächlich hilft
2. Anmeldesteuer (Sign-Up Tax)
- Nachdem man einen Dienst ausgewählt hat, muss man E-Mail-Adresse und Kreditkarteninformationen angeben
- Man muss prüfen, ob nutzungsbasierte Abrechnung möglich ist oder nur subscription-basierter Lock-in unterstützt wird
- Undurchsichtige Preisstrukturen sind problematisch, etwa wenn zusätzliche Kosten entstehen, nur damit Teammitglieder Zugriff auf das Dashboard bekommen
- Man sollte kontrollieren, ob sich der Dienst auch ohne kostenlose Testphase testen lässt oder ob von Anfang an Zahlung verlangt wird
- Noch bevor eine einzige Zeile Code geschrieben ist, entsteht bereits ein Vertragsverhältnis mit dem Anbieter
3. Integrationssteuer (Integration Tax)
- Bei der tatsächlichen Einführung sind Dokumentation prüfen, Bibliotheken installieren, das Framework anbinden und zusätzliche Probleme außerhalb der Dokumentation lösen unvermeidlich
- Häufig stößt man auf Konflikte mit Tools oder auf unerwartete Probleme
- Wenn ein SaaS-Dienst nur den kleinsten gemeinsamen Nenner adressiert, ist bei modernen Stacks oder spezialisierten Umgebungen noch mehr Arbeit nötig
4. Steuer für lokale Entwicklung (Local Development Tax)
- Es ist oft unklar, ob ein SaaS-Dienst die lokale Umgebung überhaupt unterstützt
- Benötigt werden lokale Emulatoren oder zumindest die Möglichkeit, für Tests mit Stubs zu arbeiten
- Um bestimmte Funktionen zu prüfen, sind teilweise Cloud-Tunneling und ähnliche Maßnahmen nötig, was die Umgebungskonfiguration komplizierter macht
- Verzweigungen in der Konfiguration für Production, Staging und lokal werden dadurch praktisch unvermeidlich
5. Produktionssteuer (Production Tax)
- Nach der Integration des Dienstes entstehen in der Produktionsumgebung neue Belastungen
- Auch für Staging- oder PR-Preview-Umgebungen braucht man zusätzliche Verwaltung, etwa für API-Key-Management, Monitoring, Logging und Alerts
- Man muss auf Fehler oder Inkonsistenzen vorbereitet sein, die in der Entwicklungsumgebung nicht auftreten, sondern nur im realen Betrieb
- Die Verantwortung, die Stabilität des Dienstes aufrechtzuerhalten, wird letztlich auf die Entwicklerinnen und Entwickler abgewälzt
Fazit
- Der Slogan moderner SaaS-Angebote lautet „Erfinde das Rad nicht neu“, doch mit jedem zusätzlichen Dienst kommt Reibung hinzu
- Die Einführung eines Dienstes ist nicht einfach nur eine Integration, sondern ein Vertrag und bringt mehr Abhängigkeiten sowie Änderungen an der Architektur mit sich. Vendor Lock-in ist unvermeidlich, und ein Wechsel bedeutet oft erhebliche Last durch das Umschreiben von Code.
- Deshalb ist es effizienter, statt solche Entscheidungen immer wieder zu treffen, von Anfang an eine integrierte Plattform zu wählen
- Wichtig ist die Software, die Entwicklerinnen und Entwickler tatsächlich bauen wollen
- Integrierte Plattformen wie Cloudflare oder Supabase bieten Datenbank, Queues, Bilder und Storage in derselben Umgebung und reduzieren die oben genannten Steuerlasten erheblich.
- Kein Wechseln mehr zwischen verschiedenen Anbietern nötig (Context Switching)
- Weniger Probleme beim Umgang mit API-Keys
- Minimaler Bedarf an Kompatibilitätsanpassungen und umgebungsspezifischen Konfigurationszweigen
- Konsistente Integrationserfahrung in Entwicklungs- und Produktionsumgebungen
- Solche Plattformen vermitteln fast das Gefühl, als würde alles auf derselben Maschine laufen. Sie minimieren die Distanz zwischen Code und Service und helfen dabei, etwas zurückzugewinnen, was kein SaaS bieten kann: den Flow der Entwicklung.
> Wichtig ist nicht die Wahl von Framework oder Service, sondern die Software, die ich bauen will, und den Flow dabei zu bewahren
2 Kommentare
Supabase wird hier als gutes Beispiel genannt – welche SaaS-Dienste wären dann solche, die man besser vermeiden sollte?
Hacker-News-Kommentare
Das ist eine Sichtweise, die Adam Smiths „rent seeking“ in der Gegenwart als gigantisch hochskalierte Form betrachtet.
Ich denke, dass solches wirtschaftliches Verhalten gesellschaftlich schädlich ist, daher sollte man es vermeiden und sogar kriminalisieren.
Andererseits ist auch das andere Extrem, freie Software, wirtschaftlich problematisch, weil der Aufwand von Software-Schaffenden nicht proportional zu dem ist, was Nutzer an Wert daraus ziehen.
Es wird argumentiert, dass der Kauf von Software und ein separater Servicevertrag getrennt bestehen sollten, weil beides tatsächlich eigenständigen Wert liefert.
Das Problem bei SaaS ist aus dieser Sicht, dass all das gebündelt wird und dadurch in der Praxis das Packaging viel stärker entartet als der eigentliche Service selbst.
Wenn ich davon wirklich so überzeugt wäre, müsste ich selbst ein SaaS bauen und ein Unternehmen gründen, das On-Premises-Deployment und -Betrieb anbietet, und das zu einem Preis ähnlich dem heutiger SaaS-Angebote.
Wenn man Unternehmen dieselbe Qualität, dieselben Garantien und denselben Preis wie bei SaaS bieten könnte, während sie zugleich die Kontrolle über ihre Daten behalten und Vendor Lock-in vermeiden, könnte man den Markt beherrschen.
Ich denke immer wieder darüber nach, ob man nicht einfach nur ein Binary bereitstellen und die Nutzer es auf AWS, GCP oder Cloudflare Workers ausführen lassen könnte.
Aus meiner Sicht ist SaaS als Entwickler attraktiv, aber als Konsument hasse ich diese Struktur, weshalb ich in ein ethisches Dilemma gerate.
Wenn ich Software verkaufen würde: Was mache ich, wenn Nutzer sie unerlaubt weiterverteilen? Ich könnte die Distribution dann nicht wie bei SaaS kontrollieren.
Ich bin ein FOSS-Befürworter, aber wie gesagt hat auch dieses Modell wirtschaftliche Probleme.
Ich denke auch über Dinge wie Lizenzvergabe über GitHub Sponsors nach und bei manchen Projekten über ein Modell, bei dem die Authentifizierung unter SSPL steht oder beim Kauf einer Lizenz auf BSD/MIT umgestellt wird, ähnlich wie früher bei Redis.
Allerdings frage ich mich, ob Leute das in der Praxis wirklich kaufen würden; ich erwäge auch, beide Wege zu unterstützen, habe aber keine klare Antwort und bitte um Rat.
Nebenbei: Zu meinen Projekten gehören ein Tool, mit dem jeder kostenlos Kryptowährungen erstellen kann, eine Funktion zum Übernehmen von Blogs aus YouTube sowie unbegrenzter Speicher, der YouTube-Community und Videos als Google-Fotos-Ersatz nutzt; ich denke auch über bessere Privatsphäre nach. Falls jemand Ideen zur Monetarisierung hat, würde ich sie gern hören.
Es wird darauf hingewiesen, dass bei den meisten SaaS-Angeboten für den Anbieter laufende Kosten wie Hosting, Support und R&D anfallen.
Deshalb fällt es schwer, der Logik zu folgen, warum diese Struktur „rent seeking“ sein soll.
Man kann nicht sagen, dass alles bei SaaS rent seeking ist; vielmehr wird darauf hingewiesen, dass die „stickiness“ von Software selbst ihrem Wesen nach rent seeking ähnelt.
Die meisten SaaS-Anbieter streben nach stickiness, aber das ist nicht nur eine Eigenschaft von SaaS.
Ich bin auf der Seite der Anbieter und verkaufe mein SaaS-Produkt an Kunden, die es zu einem vernünftigen Preis am Markt kaufen wollen.
Vendor Lock-in spürt man meist dann, wenn intern gefragt wird: „Warum führen wir das Tool NEWTHING nicht ein?“ und die Antwort lautet, dass man bereits einen langfristigen Fünfjahresvertrag mit Oracle, MS, IBM oder Salesforce hat und deshalb nichts machen kann.
Nach etwa zehn Jahren ist man dann wirklich vollständig an diesen Anbieter gebunden, und es entsteht eine Struktur, in der man nicht mehr wechseln kann.
Wenn ein Geschäft überhaupt lange genug besteht, um zehn Jahre zu überdauern, ist das eher ein Segen oder ein Luxusproblem. In der frühen Startup-Phase würde ich raten, nicht zu viel Zeit auf die Auswahl vieler Tools zu verwenden, sondern schnell eine Plattform zu wählen und sich darauf zu konzentrieren.
Auch in solchen Fällen sollte man Services über standardisierte Interfaces abstrahieren.
Wenn diese Abstraktion einmal vorhanden ist, muss man beim späteren Wechsel zu einem anderen Service nur noch eine alternative Implementierung bereitstellen.
Diese Vorgehensweise ist zukunftsorientiert, aber es wird angemerkt, dass viele Unternehmen darauf heute nicht ausreichend vorbereitet sind.
Die Minimierung von Abhängigkeiten ist meiner Meinung nach einer der wichtigsten Faktoren, um Produkt und Geschäft langfristig tragfähig zu machen.
In meinem früheren Job war ich dafür zuständig, eine elektronische Signaturerfahrung im Stil von DocuSign in unser Produkt zu integrieren.
Wir haben mit großen Anbietern wie DocuSign und Adobe gesprochen, stellten aber fest, dass ihre API-Einschränkungen nicht gut zu den Anforderungen unseres Produkts und unserer Kunden passten, und entschieden uns schließlich für eine Eigenentwicklung.
Normalerweise wäre es ein Fehler, ein Tool wie DocuSign selbst nachzubauen, aber unser Produkt genoss bereits das Vertrauen der Kunden, sodass die Einführungshürde gering war.
Die direkte Umsetzung bedeutete anfangs viel Arbeit, doch wenn tatsächlich kleine kundenspezifische Änderungen nötig waren, konnten wir schnell reagieren; mit einem Vendor wäre das viel umständlicher und ein größeres Projekt geworden. Daher war die Entscheidung für die Eigenentwicklung richtig.
Ich verstehe den Autor so, dass er sagt, SaaS sei Vendor Lock-in und man solle es deshalb nicht kaufen.
Gleichzeitig empfiehlt der eigentliche Text aber, sich ganz auf eine bestimmte Plattform wie Cloudflare festzulegen.
Am Ende ist jede Entscheidung irgendeine Form von Lock-in, und selbst bei Open Source oder Self-Hosting müsste man beim Ersatz große Mengen Code neu schreiben.
Die Nutzung anbieterspezifischer Funktionen und „echter Lock-in“ sind jedoch nicht dasselbe; Lock-in entsteht eher dann, wenn ein Wechsel mehr Kosten und Zeit verursacht als das Beibehalten des bisherigen Wegs.
Wenn man Software locker gekoppelt und kohärent aufbaut, ist der Austausch einzelner Teile einfacher.
Denn wenn das Interface einfach ist, ist auch der Austausch einfach.
Deshalb ist die Entscheidung „Alles ist Lock-in, also binden wir uns einfach noch stärker an eine Plattform“ aus Entwicklersicht bequem, aus Managementsicht aber eine schlechte Strategie; man sollte sich auf die Flexibilität und Veränderungsfähigkeit des Unternehmens konzentrieren.
Aus Unternehmerperspektive sollte man Lösungen wählen, die dem Unternehmen Flexibilität und Anpassungsfähigkeit geben; sich ohne Alternative an SaaS zu ketten, ist deshalb unklug.
In der Startphase oder ohne Umsatz ist die Nutzung einer Plattform vorteilhafter als SaaS; wenn man wächst und die Skalierungsphase erreicht, sollte man auch an langfristige technologische Veränderungen denken.
Ich nutze Cloudflare Workers häufig und schreibe meinen Code so, dass er überall portierbar bleibt.
Mit
wrangler devkann man lokal ausführen, und tatsächlich läuft er auch unter purem Node/Bun/Deno ohne größere Änderungen.Der OP ist nicht grundsätzlich gegen SaaS selbst (er empfiehlt am Ende ja ebenfalls as-a-service-Lösungen wie Cloudflare oder Supabase), sondern weist im Kern auf die operativen Kosten und die Belastung durch das Management zu vieler Anbieter und Beziehungen hin.
Je weniger Vendoren und je weniger Abhängigkeiten, desto einfacher wird der Betrieb.
Natürlich ist die Vorstellung, jede Funktion allein mit Standardbibliotheken umzusetzen, zu idealistisch und in der Realität sehr schwierig.
Der Kern der Empfehlung ist, am Anfang nicht viele verschiedene Services zu mischen, sondern erst einmal eine Plattform zu verwenden.
Ich bevorzuge Cloudflare, weil dort Bindings ähnlich wie
fetchstandardisiert sind und sichfetchin der Web-Welt für mich wie Unix-Pipes anfühlt.Es ist ironisch, dass man Vendor Lock-in vermeiden will, indem man alles auf eine einzige Plattform setzt und sich dadurch noch stärker an ein einzelnes Unternehmen bindet.
Denn auch SaaS hat verteilte Kosten, also eine Art „Steuer“.
Eher wirkt diese Diskussion wie ein Plädoyer für Open Source.
Mit Open Source und Self-Hosting würden die meisten im Text genannten „Steuern“ wie Kosten für Discovery, Signup, Integration und lokale Entwicklung entfallen.
Ich denke, die production tax von Open Source, also der operative Aufwand, ließe sich über ein aktives Ökosystem sowie Plugin- und Modulökosysteme lösen.
In Anlehnung an den Unterschied zwischen Religion und Kult: Wenn man seine Daten in einem Standardformat exportieren und gehen kann, ist es kein Vendor Lock-in.
Kunden fühlen sich weniger ausgeliefert, wenn sie ihre eigenen Daten mitnehmen können, aber zu viele SaaS-Dienste machen genau das unmöglich.
Aktuell veröffentliche ich meistens unter MIT und halte die wichtigen Teile nicht öffentlich.
Die Grenze von SaaS besteht darin, dass Kunden nicht von den Vorteilen der „nahezu gegen null gehenden Grenzkosten“ von Software profitieren können.
SaaS-Anbieter geben einen Teil dieses Vorteils zwar über niedrigere Preise weiter, aber sobald es viele Nutzer gibt und der Stückpreis hoch ist, sind am Ende die SaaS-Kunden im Nachteil.
Für ein Startup in der Frühphase wäre eine Eigenentwicklung jedoch eine leichtsinnige Entscheidung, und in der Phase des „Überlebens“ und der „Minimierung der Anfangskosten“ ist SaaS eine sehr kluge Strategie.
Erst wenn das Geschäft wächst und SaaS tief in den Alltag eingebettet ist, treten Probleme wie Lock-in, Migration und Wechselkosten auf.
Das SaaS-Problem ist letztlich also auch eine Nebenwirkung des Erfolgs.
Genau deshalb gibt es so unglaublich viele solcher SaaS-Modelle.
Ein Geschäftsmodell mit wiederkehrenden Einnahmen wie eine Rente und sogar mit Preissetzungsmacht ist einfach extrem attraktiv.