Letzte Woche habe ich gesehen, wie ein Nachwuchsentwickler in unserem Team innerhalb von 90 Minuten eine funktionierende CRUD-App mit Autorisierung, Datenbankmigrationen und einer halbwegs anständigen Benutzeroberfläche auf die Beine gestellt hat. Mit Copilot. Von Grund auf.
Vor fünf Jahren hätte die gleiche Aufgabe noch eine Woche gedauert. Vielleicht sogar zwei, wenn man das Herumhantieren mit Einsatzkonfigurationen und OAuth-Flows mitzählt. Und dieser Wandel, die Verkürzung der Entwicklungszeit von Tagen auf Stunden, löst eine der ältesten Fragen in der Softwarebranche auf: Sollen wir bauen oder kaufen?
Das alte Framing ist tot
Jahrzehntelang war die Frage "bauen oder kaufen" eine Kostenkalkulation. Man schätzte, wie viele Entwicklermonate es dauern würde, eine Sache zu entwickeln, multiplizierte das mit dem Gehalt, fügte einen Puffer für die Wartung hinzu und verglich das Ganze mit der jährlichen Lizenzgebühr für ein SaaS-Produkt, das in etwa das Gleiche leistete. Wenn das SaaS-Produkt billiger war, hast du es gekauft. Wenn deine Anforderungen seltsam genug waren, hast du etwas gebaut.
Bei dieser Vorgehensweise wurde davon ausgegangen, dass Bauen teuer sei. Und das war es auch. Aber [laut den Octoverse 2025-Daten von GitHub] (https://github.blog/ai-and-ml/generative-ai/how-ai-is-reshaping-developer-choice-and-octoverse-data-proves-it/) führt die KI-gestützte Entwicklung heute zu einer Steigerung des Durchsatzes um 20 bis 30 Prozent. Achtzig Prozent der neuen Entwickler auf GitHub nutzen Copilot innerhalb ihrer ersten Woche. Über 1,1 Millionen öffentliche Repositories integrieren bereits LLM-SDKs. Das Bauen wurde fast über Nacht drastisch billiger.
Die Frage lautet also nicht mehr wirklich "bauen oder kaufen". Sie lautet vielmehr: Wofür bezahlst du eigentlich, wenn du SaaS kaufst?
Das neue Kalkül
Ich glaube, die meisten SaaS-Gründer (mich eingeschlossen, ehrlich gesagt) wollen Folgendes nicht hören: Wenn dein gesamtes Wertversprechen lautet: "Wir haben dich davor bewahrt, es selbst zu entwickeln", hast du ein Problem. Denn der Wassergraben ist gerade sehr viel flacher geworden.
Wenn ein Team ein funktionierendes internes Tool an einem Tag entwickeln kann, liegt die Messlatte für die Rechtfertigung eines monatlichen Abonnements sehr hoch. Du musst nicht nur besser sein als das, was sie bauen können. Du musst besser sein als das, was sie mit Hilfe von KI bauen könnten.
[Gartner prognostizierte im April 2026 (https://www.gartner.com/en/newsroom/press-releases/2026-04-02-gartner-expects-most-enterprises-to-abandon-assistive-ai-for-outcome-focused-workflow-by-2028), dass bis zum Jahr 2028 mehr als die Hälfte aller Unternehmen nicht mehr für unterstützende Intelligenz bezahlen, sondern Plattformen bevorzugen werden, die auf Workflow-Ergebnisse setzen. Noch deutlicher: Gartner geht davon aus, dass bis 2030 die Gewinnspanne von Softwareunternehmen, die KI über bestehende Anwendungen schichten, anstatt sie für eine agentenbasierte Ausführung umzugestalten, um bis zu 80 % sinken wird.
Achtzig Prozent. Das ist kein Rundungsfehler.
Was überlebt eigentlich?
Ich habe viel über diese Frage nachgedacht, auch weil wir Rasepi bauen und ich mir selbst gegenüber ehrlich sein muss, wo unser Wert liegt. Und ich glaube, die Antwort liegt in drei Dingen, die wirklich schwer in einem Wochenend-Coding-Sprint zu erreichen sind, egal wie gut dein KI-Assistent ist.
Domänentiefe kann man nicht fälschen Jeder kann einen Texteditor bauen. Aber ein Übersetzungssystem zu entwickeln, das inhaltliche Änderungen auf Absatzebene verfolgt, veraltete Übersetzungen durch Content-Hashing erkennt und strukturelle Anpassungen in verschiedenen Sprachen vornimmt? Dafür braucht man jahrelanges Fachwissen, das in die Architektur einfließt. Die KI kann dir helfen, den Code schneller zu schreiben, aber sie kann dir nicht sagen, was du bauen sollst.
Jemand muss es immer noch ausführen und pflegen. Das ist das Schöne am Bauen: Es macht Spaß. Pflegen? Macht überhaupt keinen Spaß. Der Umgang mit Grenzfällen in mandantenfähigen Berechtigungssystemen, das Aufpassen auf Browser-Macken, das Verwalten von versionsübergreifenden Datenbankmigrationen, das Patchen von CVEs um 2 Uhr morgens, der Umgang mit dem einen PDF-Exportfehler, der nur in Safari auftritt. KI macht den ersten Build schneller, klar. Aber die [Forrester-Studie vom April 2026] (https://www.forrester.com/press-newsroom/forrester-three-years-into-genai-enterprises-are-still-chasing-its-true-transformative-value/) zeigt, dass die meisten Unternehmen immer noch nicht in der Lage sind, den Einsatz von KI in messbare Erfolge umzuwandeln, was zum Teil daran liegt, dass der schwierige Teil nie das Schreiben von Code war. Die Schwierigkeit besteht darin, das Ding am Laufen zu halten, es zu aktualisieren und über Jahre hinweg korrekt zu arbeiten. Die Entwicklung ist der einfache Teil. Es sind die Betriebszeit, die Bereitschaftsdienste und die inkrementellen Korrekturen, die dich wirklich etwas kosten.
Vertrauen, Sicherheit und Datenschutz. Dieser Punkt wird unterschätzt. Wenn du etwas selbst baust, bist du für die Sicherheit verantwortlich. Du bist verantwortlich für die Verschlüsselung im Ruhezustand, die Protokollierung von Audits, Penetrationstests, die Einhaltung der GDPR, SOC 2 und die nächste Vorschrift, von der noch niemand gehört hat. Ein guter SaaS-Anbieter hat ein ganzes Team, dessen einzige Aufgabe darin besteht, dafür zu sorgen, dass deine Daten nicht irgendwo landen, wo sie nicht sein sollten. Für die meisten Unternehmen sind das keine Kosten, die sie intern tragen wollen. Und ehrlich gesagt, haben die meisten internen Tools, die ich gesehen habe, nicht einmal eine angemessene Zugangskontrolle, geschweige denn einen Sicherheits-Audit-Trail.
The Composable Middle Ground
Interessant ist, dass die Antwort zunehmend nicht "bauen" oder "kaufen" lautet. Sie lautet "komponieren". Wähle die SaaS-Tools, die schwierige Aufgaben gut erledigen, gute APIs zur Verfügung stellen und dich um sie herum bauen lassen.
Deshalb sind Plugin-Architekturen im Moment so wichtig (und ja, genau darin haben wir mit dem Plugin-System von Rasepi investiert). Die SaaS-Produkte, die erfolgreich sein werden, sind diejenigen, die sagen: "Wir kümmern uns um die schwierigen domänenspezifischen Fragen: "Wir kümmern uns um den harten, domänenspezifischen Kern. Du passt alles andere an." Nicht: "Hier ist unser Monolith, nimm ihn oder lass es".
[Der Forrester-Bericht vom April 2026 (https://www.forrester.com/press-newsroom/forrester-three-years-into-genai-enterprises-are-still-chasing-its-true-transformative-value/) zeigt, dass die meisten Unternehmen immer noch Schwierigkeiten haben, die Einführung von KI in messbare Geschäftseffekte umzusetzen. Diejenigen, die KI bereits eingeführt haben, arbeiten mit 47 % höherer Wahrscheinlichkeit mit Beratungspartnern zusammen, um ihre Daten und Systeme vorzubereiten. Die Botschaft ist klar: Die bloße Entwicklung von Fähigkeiten ist nicht der Engpass. Der eigentliche Engpass besteht darin, zu wissen, was man bauen will, und die Infrastruktur zu haben, um es zu unterstützen.
Was das für SaaS bedeutet
Wenn du im Jahr 2026 ein SaaS-Unternehmen leitest, gibt es ein paar unangenehme Wahrheiten:
- Das Argument "Wir sparen Ihnen Zeit" ist schwächer denn je. Zeitersparnis war der klassische SaaS-Verkaufsgrund. Aber wenn KI die Entwicklungszeit um 20-30% verkürzt, schrumpft die Zahl "Zeitersparnis" in deiner ROI-Tabelle proportional dazu. Du brauchst eine andere Geschichte.
- Niemand interessiert sich dafür, dass du 47 Integrationen hast. Für sie ist es wichtig, dass ihre Dokumentation aktuell bleibt, ihre Übersetzungen korrekt sind und ihr Team das Tool tatsächlich nutzt. Was Gartner über den "ergebnisorientierten Workflow" sagt, ist nicht nur Analystenjargon. Es ist die Richtung, in die sich der Markt bewegt.
- Offenheit schlägt Abschottung Der Instinkt, die eigene Plattform zu schließen und den Wechsel zu erschweren, ist verständlich. Gartner warnte jedoch ausdrücklich davor, dass "ältere SaaS-Anbieter, die versuchen, ihre Systeme zu schließen, Gefahr laufen, von Orchestrierungsebenen umgangen zu werden, denen Unternehmen mehr vertrauen." Autsch.
Die ehrliche Version
Ich will ganz offen sagen, wo ich in dieser Sache stehe. Beim Vergleich zwischen Bauen und Kaufen ging es nie wirklich um die Technologie. Es ging immer um Vertrauen. Vertraue ich diesem Anbieter, dass er mein Problem so gut versteht, dass seine Lösung besser ist als das, was ich selbst zusammenschustern könnte?
Im Jahr 2026 wurde "zusammenschustern" massiv aufgewertet. Damit wurde auch die Vertrauenslatte höher gelegt.
Für uns bei Rasepi bedeutet das, dass wir nicht nur ein Dokumentationswerkzeug sein können, das zufällig Übersetzungen unterstützt. Wir müssen so gut in den schwierigen Problemen sein, in der Nachverfolgung von Übersetzungen auf Blockebene, in der Durchsetzung der Aktualität von Inhalten und in der Komplexität mehrerer Mandanten, dass es selbst mit den besten KI-Tools der Welt sehr mühsam wäre, einen Ersatz zu entwickeln.
Das ist das neue Build vs. Buy. Nicht "Kannst du es bauen?", sondern "Solltest du deine Energie darauf verwenden, es zu bauen, wenn jemand anderes die schwierigen Teile bereits gelöst hat?"
Die Frage war nie wirklich eine Frage der Kosten. Es ging darum, worauf du deine Aufmerksamkeit verwenden willst. Und in einer Welt, in der Bauen billig ist, ist Aufmerksamkeit die einzige knappe Ressource, die bleibt.