Die Angst geht um in der Branche. KI macht Entwickler überflüssig, heißt es. Cursor, Copilot, Claude Code - jeden Monat ein neues Tool, das verspricht, ganze Teams zu ersetzen. Am Ende stehen wir alle auf der Straße. So zumindest die Erzählung, die gerade durch jede Konferenz und jeden LinkedIn-Feed schwappt.
Ich halte diese Erzählung für falsch. Nicht weil KI die Softwareentwicklung nicht verändert. Das tut sie, und zwar massiv. Aber die Veränderung zeigt in eine andere Richtung als die meisten vermuten. Individualsoftware ist gerade deutlich billiger geworden. Und die Frage, die mich beschäftigt, ist nicht ob Entwickler überflüssig werden. Sondern was passiert, wenn sich die Make-or-Buy-Gleichung verschiebt, die unsere Branche seit Jahrzehnten bestimmt. Meine These: Wir werden nicht weniger Softwareentwicklung sehen. Wir werden sehr viel mehr davon sehen.
Die alte Gleichung
Make or Buy ist eine der ältesten Fragen in der Softwareentwicklung. Die Antwort war in den meisten Fällen: Buy. Weil Softwareentwicklung teuer war. Weil man Teams brauchte, die über Monate Features bauen, testen und warten. Weil der Abstimmungsaufwand zwischen Fachbereich und Entwicklung allein schon ein Projekt-Budget auffressen konnte.
SaaS hat diese Gleichung weiter in Richtung Buy verschoben. Keine Infrastruktur, keine Updates, kein Ops-Aufwand. Dafür eine monatliche Rechnung und die Gewissheit, dass jemand anderes sich um den Betrieb kümmert. Das Versprechen war klar: Es ist billiger, wenn wir das für tausend Kunden gleichzeitig machen, als wenn jeder es selbst baut.
Dieses Versprechen hat jahrelang funktioniert. Die ganze Branche hat davon gelebt.
Was sich gerade verschiebt
Die Geschwindigkeit, mit der Software heute entstehen kann, hat sich fundamental verändert. Nicht inkrementell. Nicht zehn Prozent schneller. Anders.
KI-gestützte Entwicklung mit Agenten, die autonom Code schreiben, Tests generieren und Bugs fixen, hat die Kosten für Softwareentwicklung massiv gedrückt. Einzelpersonen liefern in Tagen, wofür Teams vorher einen Sprint gebraucht haben. Nicht weil die Leute besser geworden sind, sondern weil sich die Werkzeuge radikal verändert haben.
Ich erlebe das in meinem eigenen Arbeitsalltag. Was früher einen Tag gedauert hat, dauert jetzt Stunden. Was Stunden gebraucht hat, geht in Minuten. Und das ist kein Vibe Coding, bei dem am Ende Code rauskommt, den keiner versteht. Das ist professionelle Softwareentwicklung mit klaren Specs, Code-Reviews und Testabdeckung. Nur deutlich schneller.
Weniger Personal, weniger Abstimmung, schnellere Ergebnisse. Das verändert die Gleichung.
Die SaaS-Preisspirale
Gleichzeitig passiert auf der Buy-Seite etwas, das die Rechnung weiter verschiebt: SaaS wird teurer. Teilweise drastisch.
Wir haben das bei uns in der Firma erlebt. Asana hat die Preise erhöht, und wir waren nicht die Einzigen, die sich gewundert haben. Lizenzen, die sich alle ein bis zwei Jahre um zwanzig, dreißig, manchmal fünfzig Prozent verteuern. Dazu kommen Features, die plötzlich nur noch in höheren Tarifen verfügbar sind. Oder KI-Funktionen, die als Aufpreis verkauft werden, obwohl sie auf den gleichen Modellen basieren, die man über eine API für einen Bruchteil nutzen könnte.
Das Per-Seat-Modell der großen SaaS-Anbieter gerät zusätzlich unter Druck, wenn KI-Agenten menschliche Nutzer teilweise ersetzen. Wenn ein Agent drei Aufgaben erledigt, für die vorher drei Lizenzen nötig waren, wird das Abrechnungsmodell absurd. Einige Anbieter reagieren darauf mit noch aggressiveren Preiserhöhungen. Das beschleunigt genau die Dynamik, die sie eigentlich verhindern wollen.
Wer sich Sorgen machen sollte
Diese Entwicklung betrifft strategisch zwei Gruppen.
SaaS-Anbieter haben ein Problem, das tiefer geht als einzelne Kündigungen. Ihr gesamtes Geschäftsmodell basiert auf dem Versprechen: Es ist günstiger, unsere Lösung zu nutzen als selbst zu bauen. Wenn die Kosten für “selbst bauen” deutlich fallen, stimmt diese Rechnung für immer mehr Anwendungsfälle nicht mehr. Besonders für interne Tools, Dashboards, Datenauswertungen, Automatisierungen. Also genau die Kategorie, in der SaaS in den letzten Jahren am stärksten gewachsen ist.
Klassische Softwaredienstleister stehen vor einer ähnlichen Frage, nur von der anderen Seite. Wer bisher davon gelebt hat, Teams in Projekte zu schicken und nach Personentagen abzurechnen, muss sich fragen, was passiert, wenn dieselbe Leistung deutlich weniger Personentage braucht. Die Leistung wird nicht weniger wert. Aber sie braucht weniger Menschen und weniger Zeit. Das ist ein Geschäftsmodell-Problem, nicht ein Effizienzproblem.
Die neue Gleichung
Die Make-or-Buy-Grenze verschiebt sich gerade still. Nicht bei den großen Systemen. Kein vernünftiger Mensch baut sich ein eigenes ERP oder CRM. Aber bei allem unterhalb dieser Schwelle verändert sich massiv, was “selbst bauen” kostet.
Ein Reporting-Dashboard? Früher drei Monate Projektlaufzeit, heute ein Wochenende mit dem richtigen Setup. Ein internes Planungstool? Früher ein halbes Team für ein halbes Jahr, heute eine Person für zwei Wochen. Eine Integration zwischen zwei Systemen, für die der SaaS-Anbieter einen Enterprise-Tarif verlangt? Ein paar Tage mit einem Agenten und einer API.
Das heißt nicht, dass jede Organisation jetzt alles selbst bauen sollte. Aber die Schwelle, ab der “selbst bauen” wirtschaftlich Sinn ergibt, ist deutlich gesunken. Und sie sinkt weiter.
Aber
Es wäre naiv, nur die Kostenseite zu sehen. Individualsoftware hat nach wie vor Nachteile, die nicht verschwinden, nur weil die Entwicklung billiger wird.
Wartung. Wer Software baut, muss sie pflegen. Security-Updates, Dependency-Management, Bugfixes. Das hört nicht auf, wenn das Feature live ist. KI-Agenten können dabei helfen, aber die Verantwortung bleibt.
Architektur. Schnell gebaute Software kann schnell zum Problem werden, wenn niemand über Struktur nachgedacht hat. Ein Prototyp, der “nur mal schnell” entstanden ist und plötzlich in Produktion läuft. Ohne Tests, ohne Dokumentation, ohne jemanden der den Code versteht. Das passiert jetzt häufiger, nicht seltener.
Domänenwissen. Die beste KI schreibt den falschen Code, wenn die Anforderung falsch ist. “Was soll die Software eigentlich tun?” ist nach wie vor die schwierigste Frage in jedem Projekt. Und sie wird nicht einfacher, nur weil die Umsetzung schneller geht.
Was das für Entscheidungen bedeutet
Die Frage, die sich gerade jede Organisation stellen sollte, ist nicht “Build vs. Buy”. Sie ist: Für welche Teile unserer Softwarelandschaft stimmt die Buy-Rechnung noch, und wo hat sich die Gleichung verschoben?
Wer heute Make or Buy entscheidet und dabei die Entwicklungskosten von 2024 ansetzt, trifft eine Entscheidung auf Basis veralteter Daten. Die Annahme “das lohnt sich nicht” basiert in vielen Fällen auf einer Kalkulation, die nicht mehr stimmt.
Das ist keine einmalige Entscheidung. Das ist eine Frage, die man regelmäßig neu stellen muss, weil sich die Kostenstruktur gerade im Quartalstakt verändert.
Individualsoftware wird günstiger. Nicht ein bisschen. Fundamental. Und wer das in seiner Strategie nicht berücksichtigt, zahlt für Lösungen, die er nicht mehr braucht.