Die alte Rechnung stimmt nicht mehr
Jahrelang war die Entscheidung "Make or Buy" in der Softwareentwicklung eine einfache Kalkulation: Eigenentwicklung ist teuer, dauert lange und bindet Ressourcen. Fertige SaaS-Lösungen sind günstiger, schneller verfügbar und werden vom Anbieter gewartet. Im Zweifel kaufen.
Diese Rechnung hat sich verschoben — deutlich.
Ich erlebe das in meiner eigenen Arbeit: Eine Custom-Shopify-App, die ich für Fissler als DSGVO-konforme Alternative zu einer App-Store-Lösung gebaut habe, hätte vor zwei Jahren doppelt so lange gedauert. KI-Tools haben den Entwicklungsprozess beschleunigt — nicht weil sie die schwierigen Entscheidungen abnehmen, sondern weil sie die Routine eliminieren, die früher den Großteil der Zeit gefressen hat.
KI-gestützte Entwicklungstools haben die Kosten und den Zeitaufwand für Eigenentwicklung messbar reduziert. Laut einer McKinsey-Studie von Anfang 2026 (4.500 Entwickler, 150 Unternehmen) reduzieren KI-Coding-Tools den Zeitaufwand für Routine-Programmierung um 46%. Andere Studien berichten von 30-60% Zeitersparnis bei Boilerplate-Code — wobei die Ergebnisse stark vom Kontext und der Erfahrung des Entwicklers abhängen.
Gleichzeitig steigen die Kosten auf der Buy-Seite: Laut Forrester berichten 79% der IT-Entscheider von gestiegenen Softwarekosten. Features werden hinter höheren Tier-Stufen versteckt, und die Abhängigkeit von einzelnen Anbietern wird zunehmend zum strategischen Risiko.
Das Ergebnis: 35% der Teams haben laut einer Retool-Studie von 2026 bereits mindestens ein SaaS-Tool durch eine Eigenentwicklung ersetzt. 78% planen, in den kommenden Monaten weitere Custom-Tools zu bauen. (Einschränkung: Die Studie wurde unter Retool-Kunden durchgeführt — eine Zielgruppe, die ohnehin Build-affin ist. Die Zahlen sind nicht repräsentativ für den Gesamtmarkt, aber sie zeigen einen klaren Trend.)
Was sich konkret verändert hat
Prototypen in Stunden statt Wochen
Was früher ein zweiwöchiger Sprint war — ein funktionaler Prototyp mit Datenbank, API und Frontend — ist heute eine Sache von Stunden bis wenigen Tagen. KI-Coding-Tools generieren Boilerplate-Code, schlagen Architekturen vor, schreiben Tests und übernehmen die repetitiven Aufgaben, die früher den Großteil der Entwicklungszeit ausmachten.
Für einen konkreten Anwendungsfall: Wenn ein Shopify-Händler ein internes Dashboard braucht, das Bestelldaten aus mehreren Shops aggregiert, war die alte Antwort "Nimm eine SaaS-Lösung für 200€/Monat". Die neue Antwort kann sein: "Lass uns das in einer Woche bauen — genau auf eure Bedürfnisse zugeschnitten, ohne monatliche Kosten, ohne Datenabfluss an Dritte."
Die Schwelle für "lohnt sich" ist gesunken
Früher lohnte sich Eigenentwicklung erst ab einer gewissen Komplexität und Nutzungsdauer. Ein Tool, das nur drei Leute nutzen, für 50.000€ zu entwickeln — das ergab selten Sinn.
Heute liegt die Schwelle deutlich niedriger. Wenn ein KI-unterstützter Entwickler dasselbe Tool in zwei Wochen statt drei Monaten baut, ändern sich die Zahlen fundamental. Plötzlich konkurriert eine maßgeschneiderte Lösung nicht mit "ein Entwickler für drei Monate", sondern mit "ein Entwickler für zehn Tage".
SaaS-Fatigue ist real
Die Kehrseite der SaaS-Ära zeigt sich immer deutlicher. Unternehmen jonglieren mit Dutzenden von Abo-Tools, jedes mit eigener Oberfläche, eigener Datenstruktur und eigenen API-Limitierungen. Die Kosten summieren sich — nicht nur finanziell, sondern auch in Form von Komplexität, Datensilos und Einarbeitungszeit.
Dazu kommt ein Kontrollverlust: Wenn der SaaS-Anbieter sein Pricing ändert, ein Feature entfernt oder den Service einstellt, stehen Sie mit leeren Händen da. Ihre Daten, Ihre Workflows, Ihre Abhängigkeiten — alles liegt in der Hand eines Dritten.
Der gefährliche Trugschluss: Prototyp ≠ Produkt
Und jetzt kommt das große Aber.
Die Tatsache, dass KI-Tools Prototypen schneller erzeugen können, bedeutet nicht, dass Eigenentwicklung trivial geworden ist. Es gibt einen entscheidenden Unterschied zwischen einem funktionierenden Prototyp und einer produktionsreifen Software.
Die letzten 20% sind immer noch 80% des Aufwands. Ein Prototyp funktioniert auf dem Laptop des Entwicklers. Ein Produkt muss funktionieren für alle Nutzer, zu jeder Zeit, unter Last, mit fehlerhaften Eingaben, über Zeitzonen hinweg, DSGVO-konform, sicher gegen Angriffe, wartbar für die nächsten Jahre.
Konkret heißt das:
- Sicherheit: KI-generierter Code kann Sicherheitslücken enthalten, die auf den ersten Blick nicht sichtbar sind. SQL-Injection, XSS, unsichere API-Endpoints — das alles muss manuell geprüft werden.
- Error Handling: Der Prototyp funktioniert mit den Daten, die er kennt. Was passiert bei unerwarteten Eingaben? Bei Netzwerkfehlern? Bei Race Conditions?
- Performance unter Last: Eine Lösung, die für 10 Nutzer funktioniert, kann bei 1.000 Nutzern zusammenbrechen.
- Wartbarkeit: Wer pflegt die Lösung in einem Jahr? KI-generierter Code ist nicht automatisch verständlicher Code.
- Compliance: DSGVO, Datenschutz, Aufbewahrungsfristen — das alles muss von Anfang an mitgedacht werden, nicht nachträglich aufgepfropft.
Hier liegt der Wert von Erfahrung: Nicht im Schreiben von Code — das können KI-Tools immer besser. Sondern im Wissen, welcher Code geschrieben werden muss, welche Randfälle existieren und welche Architekturentscheidungen sich in zwei Jahren rächen.
Wann Build die richtige Wahl ist
1. Wenn die SaaS-Lösung 80% kann, aber die fehlenden 20% geschäftskritisch sind
Sie haben eine Projektmanagement-Software, die fast alles kann, was Sie brauchen — nur die Integration mit Ihrem ERP fehlt. Der SaaS-Anbieter hat die auf der Roadmap, "irgendwann". In der Zwischenzeit exportieren Ihre Mitarbeiter täglich Excel-Dateien.
Früher hätten Sie gewartet oder einen teuren Workaround gebaut. Heute kann eine maßgeschneiderte Lösung, die genau diese Lücke schließt, in wenigen Wochen stehen.
2. Wenn Datenschutz und Compliance es erfordern
In meiner Arbeit mit Shopify-Enterprise-Kunden erlebe ich das regelmäßig: Eine App aus dem Shopify App Store macht technisch, was sie soll. Aber sie verarbeitet Kundendaten auf Servern in den USA, ohne DSGVO-konforme AVV, ohne Transparenz über die Datenverarbeitung.
Die Alternative: Eine Custom-Shopify-App, die genau die benötigte Funktionalität bietet, dabei nur die Daten verarbeitet, die sie braucht, und deren Datenflüsse Sie vollständig kontrollieren.
3. Wenn die Abhängigkeit vom Anbieter zum Risiko wird
Wenn ein einzelnes SaaS-Tool in einem kritischen Geschäftsprozess steckt und es keine echte Alternative gibt, ist das ein strategisches Risiko. Preiserhöhungen, Feature-Änderungen oder die Einstellung des Dienstes können Sie unvorbereitet treffen.
4. Wenn der Use Case zu spezifisch für eine Standardlösung ist
Manche Geschäftsprozesse sind so individuell, dass keine Standardlösung sie sauber abbildet. Wenn Sie drei SaaS-Tools mit Workarounds verbinden müssen, um einen Prozess abzubilden, den eine maßgeschneiderte Lösung in einem Tool erledigen könnte, ist Build oft die langfristig günstigere Option.
Wann Buy weiterhin die bessere Wahl ist
1. Wenn das Problem ein gelöstes Problem ist
E-Mail-Versand, Zahlungsabwicklung, Analytics, CRM — für diese Standardprobleme gibt es ausgereifte Lösungen, die von ganzen Teams weiterentwickelt werden. Eine eigene Zahlungsabwicklung zu bauen, weil KI-Tools Code schneller schreiben, wäre Irrsinn.
2. Wenn die Wartung den Build-Vorteil auffrisst
Eine selbst gebaute Lösung muss gepflegt werden. Updates, Bugfixes, Sicherheitspatches, Anpassungen an neue Browser-Versionen oder API-Änderungen. Wenn Sie kein Team haben, das diese Wartung langfristig übernimmt, kann eine SaaS-Lösung trotz höherer monatlicher Kosten günstiger sein.
3. Wenn die Time-to-Market entscheidend ist
Ein SaaS-Tool ist sofort einsatzbereit. Eine Eigenentwicklung — auch eine KI-beschleunigte — braucht Konzeption, Entwicklung, Testing und Deployment. Wenn Sie eine Lösung morgen brauchen und nicht in vier Wochen, ist Buy die pragmatische Wahl.
Die dritte Option: Build on Top of Buy
In der Praxis ist die Entscheidung selten rein binär. Der häufigste Ansatz ist ein Hybrid: Eine bewährte SaaS-Plattform als Basis, ergänzt um maßgeschneiderte Erweiterungen.
Shopify selbst ist das beste Beispiel: Sie kaufen die Plattform, aber bauen Custom Apps, Checkout Extensions und Integrationen on top. Sie nutzen die Infrastruktur eines ausgereiften Produkts und entwickeln nur dort selbst, wo Ihre Anforderungen über den Standard hinausgehen.
Dieser Ansatz vereint die Stärken beider Seiten: Die Stabilität und Wartung einer etablierten Plattform, kombiniert mit der Flexibilität maßgeschneiderter Erweiterungen. KI-Tools machen genau diesen Hybrid-Ansatz noch attraktiver — weil die Custom-Komponenten schneller und günstiger entstehen als früher.
Wie KI die Rolle des Entwicklers verändert
KI-Tools ersetzen keine Entwickler. Sie verschieben den Schwerpunkt ihrer Arbeit.
Weniger Zeit geht für Routine-Code drauf: Boilerplate, Standard-Implementierungen, Datenbank-Migrationen. Mehr Zeit bleibt für die Aufgaben, die Erfahrung und Urteilsvermögen erfordern: Architekturentscheidungen, Sicherheits-Reviews, Performance-Optimierung, Integration in bestehende Systeme.
Das bedeutet: Ein erfahrener Entwickler mit KI-Tools ist nicht nur schneller — er kann komplexere Projekte stemmen, die ohne KI-Unterstützung für eine Einzelperson nicht realisierbar gewesen wären. Die Kombination aus Domänenwissen und KI-Beschleunigung ist der eigentliche Produktivitätssprung.
Fazit
Make-or-Buy ist 2026 keine binäre Entscheidung mehr. KI hat die Build-Seite der Gleichung grundlegend verändert — Eigenentwicklung ist schneller, günstiger und zugänglicher als je zuvor.
Aber KI hat nicht die Grundregeln der Softwareentwicklung außer Kraft gesetzt. Ein Prototyp ist kein Produkt. Sicherheit, Wartbarkeit und Compliance erfordern Erfahrung, nicht nur Geschwindigkeit.
Die kluge Strategie ist differenziert: Buy für gelöste Standardprobleme. Build für alles, was Ihren Wettbewerbsvorteil ausmacht, datenschutzkritisch ist oder zu spezifisch für Standardlösungen. Und für die Build-Seite: ein erfahrener Entwickler, der KI als Beschleuniger nutzt — nicht als Ersatz für Urteilsvermögen.
