Make or buy, neu gerechnet

Ende August 2024 erzählte Sebastian Siemiatkowski, Gründer und CEO des schwedischen Zahlungsdienstleisters Klarna, seinen Investoren fast beiläufig, man habe soeben Salesforce abgeschaltet. Workday, das Personalsystem, folge in wenigen Wochen; man sei dabei, eine ganze Reihe von SaaS-Anbietern stillzulegen (1). Marc Benioff, der Salesforce-Chef, reagierte öffentlich ratlos und wollte wissen, womit genau Klarna seine Kunden-, Finanz- und Personaldaten künftig zu verwalten gedenke (2).

Die Antwort fiel nüchterner aus als die Schlagzeilen, und sie ist gerade deshalb aufschlussreich. Klarna hat die beiden Systeme nicht durch einen Zauberkasten namens KI ersetzt, sondern durch eine Kombination: eigene Entwicklungen auf einer konsolidierten Datenarchitektur, dazu einige schlankere Mietdienste für das, was austauschbar ist (2). Die Entscheidung, die Klarna damit getroffen hat, liegt eine Ebene tiefer als das übliche Entweder-oder von Miete und Eigenbau: welche Schichten eines Systems ein Unternehmen selbst kontrollieren sollte und welche es getrost mieten kann.

Parallel dazu stieg Klarnas Umsatz pro Mitarbeiter von rund 344.000 Dollar im Jahr 2022 auf 1,24 Millionen Dollar Ende 2025 (3). Wie viel davon auf die Softwareentscheidung zurückgeht, lässt sich seriös kaum beziffern, dafür veränderte sich im selben Zeitraum zu viel; allein der Personalbestand schrumpfte um 49 Prozent. Als Klimadaten taugt die Zahl trotzdem: Sie zeigt, unter welchem Effizienzdruck solche Entscheidungen inzwischen fallen. Die eigentliche Nachricht war, dass ein Unternehmen diese Rechnung überhaupt wieder aufmacht.

Wer in den vergangenen zwei Jahrzehnten vor der Frage stand, ob er ein CRM, ein Kassensystem oder eine Projektsteuerung selbst entwickeln lässt oder mietet, bekam fast immer dieselbe Empfehlung: mieten. Zu Recht. Individualsoftware bedeutete Lastenheft, monatelange Entwicklung, sechsstellige Budgets und das Risiko, am Ende ein System zu besitzen, das niemand mehr warten kann. SaaS bedeutete Kreditkarte, Onboarding am Nachmittag, kalkulierbare Kosten pro Kopf und Monat. Die Anfangshürde lag auf der einen Seite bei mehreren hunderttausend Euro, auf der anderen bei neunundvierzig.

Diese Asymmetrie hat eine ganze Generation von IT-Entscheidungen geprägt. Sie hat sich so tief eingegraben, dass sie heute wie ein Naturgesetz behandelt wird: Eigenentwicklung ist teuer, Miete ist günstig. Beide Hälften dieses Satzes verdienen inzwischen eine Prüfung.

Zunächst die zweite Hälfte. Der SaaS-Inflationsindex des Beschaffungsdienstleisters Vertice, der auf Vertragsdaten von über 30 Milliarden Dollar verwaltetem Softwarebudget beruht, weist für März 2026 eine Preissteigerung von 13,2 Prozent gegenüber dem Vorjahr aus, fast das Fünffache der allgemeinen Inflationsrate der G7-Staaten (4). Ende 2025 gab ein durchschnittliches Unternehmen nach denselben Daten rund 9.100 Dollar pro Mitarbeiter und Jahr für Softwaremieten aus, zwei Jahre zuvor waren es noch 7.900 (5).

Vertice verdient am Einkauf von Software und hat ein Interesse daran, das Problem groß zu zeichnen; die Richtung der Kurve bestätigen allerdings auch die Preislisten der Anbieter selbst. Bei Salesforce kostet die Sales Cloud in der Enterprise-Edition 175 Dollar pro Nutzer und Monat, die Unlimited-Edition 350 Dollar, die oberste Ausbaustufe Agentforce 1 Sales 550 Dollar, jeweils bei jährlicher Abrechnung (6). Im August 2025 hob der Konzern die Listenpreise der Enterprise- und Unlimited-Editionen um durchschnittlich sechs Prozent an (7).

Dazu kommt eine Praxis, die Beobachter Shrinkflation nennen: Funktionen wandern in höhere Tarife, Kontingente schrumpfen, KI-Features werden als Aufpreis verpackt, obschon sie beim Wettbewerber längst zum Standard gehören. Und über allem steht die Logik des Seats. Jede Neueinstellung erhöht die Softwarerechnung, jedes Wachstum wird mitversteuert, und nach zehn Jahren Miete steht am Ende kein System, nur ein Stapel Quittungen.

Nun die erste Hälfte des Naturgesetzes. In einem frühen kontrollierten Experiment lösten Entwickler mit GitHub Copilot eine klar umrissene Aufgabe, die Implementierung eines HTTP-Servers, um 55,8 Prozent schneller als die Kontrollgruppe (8). Solche Laborwerte markieren die Obergrenze für eng umrissene Aufgaben. Näher am Arbeitsalltag liegen drei Feldexperimente mit knapp 4.900 Entwicklern bei Microsoft, Accenture und einem weiteren Großunternehmen: Mit KI-Assistenz erledigten die Teams gut 26 Prozent mehr Aufgaben (9). Neuere agentische Werkzeuge übernehmen inzwischen ganze Arbeitsschritte; verlässliche Zahlen für ihre Wirkung auf vollständige Entwicklungsprojekte stehen noch aus.

Günstig geworden ist vor allem der wiederkehrende Mittelbau der Entwicklung: Datenmodelle, Formulare, Schnittstellen, Testabdeckung, Migrationen, administrative Oberflächen. In klassischen Kalkulationen, unsere eigenen eingeschlossen, machte dieser Mittelbau lange einen erheblichen Teil des Aufwands aus. Wie stark er ein Gesamtprojekt verbilligt, hängt von dessen Fachlogik ab; am größten ist der Effekt dort, wo ein Team auf einer etablierten Plattform arbeitet und Datenmodelle, Module und Testabläufe bereits vorhanden sind. Dann schrumpfen Aufwände, die vor drei Jahren Wochen kosteten, auf Tage. Die Anfrage, die sich früher nur ein Konzern leisten konnte, ist im Mittelstand angekommen.

Der Ehrlichkeit halber: Die Forschung ist weniger eindeutig, als Anbieterprospekte nahelegen. Eine viel diskutierte Studie des Forschungsinstituts METR fand 2025, dass erfahrene Entwickler in ihnen bestens vertrauten, komplexen Open-Source-Projekten mit den damaligen Werkzeugen im Schnitt sogar langsamer arbeiteten, während sie sich selbst für schneller hielten (10).

METR stuft dieses Ergebnis inzwischen als historisch ein und hält es für wahrscheinlich, dass heutige agentische Werkzeuge tatsächlich beschleunigen; wie stark, ließ sich in der Folgeerhebung wegen erheblicher Auswahleffekte nicht zuverlässig beziffern (11). Der Produktivitätsgewinn ist real, er ist allerdings an eine Bedingung geknüpft: Er entsteht dort, wo erfahrene Teams die Maschine führen statt ihr zu folgen.

Teuer bleiben deshalb genau die Dinge, die schon immer den Wert guter Individualsoftware ausmachten: Architektur, Fachlogik, Sicherheit, Betrieb, das Verständnis der Prozesse, die abgebildet werden sollen. Der teure Teil der Softwareentwicklung war nie das Tippen. Er ist es umso weniger, seit das Tippen fast nichts mehr kostet. Für die Kalkulation heißt das: Der Preis sinkt deutlich, der Anspruch nicht.

Eine Modellrechnung, bewusst vereinfacht und als Szenario zu lesen. Ein mittelständisches Unternehmen mit fünfzig Nutzern mietet für Kundenverwaltung, Projektsteuerung und Dokumentenprozesse drei bis vier Werkzeuge, zusammen etwa 150 Euro pro Kopf und Monat, also 90.000 Euro im Jahr. Ein maßgeschneidertes System, das diese Werkzeuge für klar umrissene Prozesse ersetzt und auf einer vorhandenen technischen Plattform entsteht, kostet in der Entwicklung 130.000 bis 150.000 Euro, dazu jährlich rund 25.000 Euro für Betrieb, Pflege und Weiterentwicklung.

Im ersten Jahr ist die Eigenentwicklung klar teurer. Dann kreuzen sich die Linien: je nach Entwicklungsaufwand und Preisentwicklung der Mieten zwischen dem Ende des zweiten und dem Verlauf des dritten Jahres. Ab diesem Punkt spart das eigene System in diesem Szenario Jahr für Jahr einen fünfstelligen Betrag. Hält die Preisentwicklung der vergangenen Jahre an, wächst der Abstand weiter. Wer die Rechnung ernsthaft führt, nimmt auf beiden Seiten die vollen Kosten hinein: bei der Miete auch Implementierung, Integrationen, Add-ons und die Kosten des späteren Ausstiegs; beim Eigenbau auch Datenmigration, Schulung und die Verantwortung für ein Produkt, das jemand im Haus dauerhaft ernst nehmen muss.

Und dann sind da die Posten, die sich schwer in Zahlen fassen lassen und im Alltag am schwersten wiegen. Das eigene System bildet die Prozesse ab, wie sie im Haus tatsächlich laufen, statt die Organisation an die Vorstellungen eines Anbieters aus San Francisco anzupassen. Oft verbessert es sie nebenbei: Schon die Anforderungsanalyse zwingt dazu, Abläufe zu klären und zu entschlacken, bevor die erste Zeile Code entsteht.

Webbasiert gebaut, teilt es zudem alle Eigenschaften, die SaaS populär gemacht haben, vom Browser als Oberfläche über zentrale Updates bis zur Verfügbarkeit im Homeoffice wie im Außendienst; was am Mietmodell attraktiv war, ist die Auslieferungsform, und die lässt sich besitzen. Speicherorte, Zugriffswege und Auftragsverarbeiter lassen sich selbst bestimmen; internationale Übermittlungsketten, die unter der DSGVO Zusatzaufwand bedeuten, lassen sich vermeiden oder wenigstens transparent kontrollieren. Der einundfünfzigste Nutzer löst keine weitere Lizenzrechnung aus. Und je nach Rechnungslegungsstandard und Ausgestaltung kann eine Eigenentwicklung zumindest teilweise als immaterieller Vermögenswert aktiviert werden, mit den zugehörigen Abschreibungen; reine Mietgebühren bleiben dagegen laufender Aufwand.

Damit kein Missverständnis entsteht: Die Umkehrung des alten Dogmas wäre so falsch wie das Dogma selbst. Standardsoftware bleibt überlegen bei Prozessen, die austauschbar sind, die nur wenige Menschen nutzen oder deren gesetzliche Grundlagen ein Anbieter laufend nachpflegen muss; sie bleibt es auch überall dort, wo im Haus niemand dauerhaft Produktverantwortung übernehmen kann. Wer seine Lohnabrechnung, seine Videokonferenzen oder seine Finanzbuchhaltung selbst entwickelt, nur weil er es jetzt könnte, hat die Lektion falsch verstanden.

Bauen lohnt sich bei Prozessen, die einen Wettbewerbsvorteil oder institutionelles Wissen enthalten, an denen viele Nutzer über viele Jahre beteiligt sind oder in denen mehrere Systeme und Datenbestände zusammenwachsen müssen. Und es lohnt sich dort, wo der Seat-Preis mit jedem Wachstumsschritt mitwächst. Kurz: Man mietet das Austauschbare und besitzt das Eigene.

Make or buy war immer eine Preisfrage, die sich als Grundsatzfrage verkleidet hat. Zwanzig Jahre lang beantwortete der Preis sie von allein, und die Antwort hieß Miete. Diese Automatik ist dahin: Die Herstellungskosten eigener Software fallen, die Mietkosten steigen, und dazwischen öffnet sich ein Raum für Entscheidungen, die lange niemand treffen musste.

Die Frage ist nicht mehr, ob man sich eigene Software leisten kann. Die Frage ist, welche Teile seiner digitalen Handlungsfähigkeit man besitzen und kontrollieren will.