Make or Buy mit KI-Agenten: Wann sich eigene Software mit Claude Code lohnt
Jens Bohse13.11.2026
Wann KI-Agenten die Rechnung zugunsten eigener Software verschieben und wann Standardsoftware die bessere Wahl bleibt
Inhalt
- Was bedeutet Make or Buy bei Software?
- Welche Kriterien entscheiden über Make or Buy?
- Was kosten Kaufen und Eigenentwicklung wirklich?
- Wann lohnt sich die Eigenentwicklung mit KI-Agenten?
- Welche Tools helfen bei der Eigenentwicklung?
- Wann ist Standardsoftware die bessere Wahl?
- Welche Risiken bringt eigene Software mit sich?
- Wie triffst du die richtige Make-or-Buy-Entscheidung?
- Fazit: Eigenentwicklung lohnt sich nicht immer
Das Wichtigste in Kürze
- KI-Agenten senken den Entwicklungsaufwand für eigene Software deutlich, dennoch bleibt der tatsächliche Nutzen für den individuellen Prozess entscheidend.
- Eine Eigenentwicklung lohnt sich vor allem bei spezifischen Kernprozessen, bei denen umständliche Workarounds in Standardlösungen dauerhaft wertvolle Zeit kosten.
- Für stark standardisierte Abläufe ist fertige Standardsoftware (SaaS) aufgrund ausgelagerter Updates und geringerer Wartungsaufwände meist die wirtschaftlichere Wahl.
- Die finale Make-or-Buy-Entscheidung sollte auf den langfristigen Gesamtkosten (TCO) basieren und auch Opportunitätskosten durch Zeitersparnisse einbeziehen.
- Unternehmen dürfen bei eigenen KI-Lösungen die langfristigen Ressourcen für den technischen Betrieb, Updates und die Vermeidung technischer Schulden nicht unterschätzen.
Wissen von den Besten: Dieser Artikel stammt von sorgfältig ausgewählten Branchen-Expert*innen. Unser Anspruch: fundierte Insights und praxiserprobte Tipps, die dich und dein Projekt wirklich weiterbringen. Erfahre hier mehr über die Autor*innen.
Selbst machen oder einkaufen? Vor dieser Frage stehen Unternehmen immer dann, wenn sie entscheiden müssen, ob sie etwas inhouse herstellen oder einen externen Anbieter damit beauftragen. Die Betriebswirtschaft nennt das Make or Buy. Bei Software geht es entsprechend darum, eine fertige Anwendung zu kaufen oder eine eigene Lösung zu entwickeln.
Durch die heutigen Möglichkeiten künstlicher Intelligenz, speziell durch KI-Agenten wie Claude Code, haben sich die Voraussetzungen für diese Abwägung erheblich verändert. Denn eigene Programme lassen sich damit in vielen Fällen deutlich schneller und mit weniger Aufwand erstellen als noch vor einigen Jahren.
Bei bakedwith habe ich regelmäßig mit dieser Thematik zu tun und kenne die kritischen Punkte von beiden Seiten. Aus dieser Erfahrung weiß ich: Es kommt weniger darauf an, wie einfach sich Software heute programmieren lässt, als vielmehr darauf, ob eine individuelle Anwendung den betreffenden Prozess tatsächlich besser löst.
Was bedeutet Make or Buy bei Software?
Die klassische Make-or-Buy-Entscheidung stammt aus der Produktionswirtschaft. Ein Automobilhersteller muss zum Beispiel abwägen, ob er ein bestimmtes Bauteil selbst fertigt oder von einem Zulieferer bezieht. Dabei spielen neben den Kosten auch die verfügbaren Kapazitäten, die Qualität und die Abhängigkeit von externen Partnern eine Rolle.
Im Softwarebereich funktioniert das Prinzip ähnlich. Angenommen, ein Unternehmen benötigt ein System zur Verwaltung seiner Kundenkontakte. Es kann eine fertige CRM-Software einkaufen oder eine eigene Anwendung entwickeln, die genau auf seine Vertriebsabläufe zugeschnitten ist. Im Englischen heißt das Build vs. Buy oder Build or Buy.
In der Praxis ist Make or Buy meiner Erfahrung nach allerdings selten ein reiner Entweder-oder-Entschluss. Gerade bei Software gibt es zwischen dem Kauf einer fertigen Anwendung und der vollständigen Eigenentwicklung zwei weitere Optionen, die manchmal sinnvoller sind. So kann es je nach Bedarf schon reichen, bestehende Programme anzupassen oder verschiedene Systeme effizienter miteinander zu verbinden.
Gerade durch die heutigen KI-Möglichkeiten ist der Markt inzwischen sehr breit geworden, sodass sich eine gründliche Prüfung vor einer Eigenentwicklung umso mehr lohnt. Der Software Guide KI von OMR Reviews zeigt beispielsweise, wie viele spezialisierte Lösungen für unterschiedliche Geschäftsprozesse bereits existieren.
Dass Unternehmen dennoch recht häufig selbst entwickeln, belegt unter anderem die McKinsey-Studie zum Stand der KI 2026. Darin geben 32 Prozent der Befragten an, dass ihr Betrieb mindestens einen Softwarekauf verworfen hat, weil sich die benötigte Funktion mithilfe von KI-Coding-Agenten intern umsetzen ließ. Das bedeutet keineswegs, dass Eigenentwicklung grundsätzlich wirtschaftlicher ist. Aber die bisherige Make-or-Buy-Rechnung verändert sich.
Welche Kriterien entscheiden über Make or Buy?
Ob eine Eigenentwicklung sinnvoll erscheint, hängt für mich vor allem davon ab, wie speziell ein Prozess ist und wie häufig er gebraucht wird. Um das beurteilen zu können, muss ich zunächst verstehen, wo die eigentlichen Schwierigkeiten liegen. Müssen Mitarbeiter*innen täglich Daten manuell zwischen Anwendungen übertragen? Oder fehlt lediglich eine Funktion, die sich in der vorhandenen Software ergänzen lässt?
Besonders interessant wird die Eigenentwicklung, wenn ein Unternehmen seine Abläufe ständig an eine Standardsoftware anpassen muss. Solche Workarounds kosten oft mehr Zeit, als im ersten Moment auffällt. Betrifft das zudem eine der Kernkompetenzen, kann individuelle Software sogar zum Wettbewerbsvorteil werden. Schließlich soll die Technik den Geschäftsprozess unterstützen und nicht umgekehrt.
Für eine erste Make-or-Buy-Analyse nutze ich gerne eine einfache Entscheidungsmatrix. Sie hilft, die vier grundsätzlichen Möglichkeiten voneinander abzugrenzen:
Ausgangslage | Meine erste Wahl | Begründung |
|---|---|---|
Üblicher Prozess ohne besondere Anforderungen | Kaufen | Bewährte Funktionen sind bereits vorhanden. |
Passende Software mit kleineren Lücken | Anpassen | Die bestehende Lösung lässt sich weiterverwenden. |
Wiederkehrende manuelle Übergaben zwischen Anwendungen | Automatisieren | Verbindungen lösen das Problem ohne neue Software. |
Häufiger, stark individueller Kernprozess | Selbst entwickeln | Die Anwendung folgt dem tatsächlichen Arbeitsablauf. |
Diese Einordnung ist natürlich noch keine vollständige Nutzwertanalyse. Dafür müssen Verantwortliche (ggf. gemeinsam mit mir als Dienstleister) die relevanten Kriterien gewichten, etwa Kosten, Anpassbarkeit und langfristige Abhängigkeiten.
Wichtig ist mir außerdem, die späteren Nutzer*innen früh einzubeziehen. Laut der OMR-Studie zu Softwareentscheidungen konsultieren 39 Prozent der befragten Führungskräfte zunächst die eigene IT. Deren technische Einschätzung ist wichtig, doch die Fachabteilungen kennen die alltäglichen Abläufe oft besser. Im direkten Austausch erfahren wir deshalb häufig erst, welche vermeintlich kleinen Arbeitsschritte besonders viel Zeit kosten.
Was kosten Kaufen und Eigenentwicklung wirklich?
Ein fairer Kostenvergleich muss die gesamten Ausgaben über mehrere Jahre berücksichtigen. Ich rechne dafür gerne über 36 Monate und nutze den Ansatz der Total Cost of Ownership (TCO). Gemeint sind sämtliche Aufwände, die mit Anschaffung oder Entwicklung und dem anschließenden Betrieb einer Software in Verbindung stehen.
- Beim Zukauf fallen typischerweise Lizenzgebühren sowie Leistungen für die Einrichtung und gegebenenfalls Anpassungen an.
- Bei einer Eigenentwicklung muss ich dagegen schon vor dem eigentlichen Programmieren Zeit in die Anforderungen und die Datenstruktur investieren. Dazu kommen später Hosting, KI-Nutzung sowie Wartung und Betrieb.
Wie sich das auswirkt, zeigt eine vereinfachte Modellrechnung. Als Beispiel nehmen wir einen internen Workflow, den zwölf Personen nutzen. Die folgenden Zahlen sind fiktive Annahmen und stammen nicht aus einem meiner Projekte.
Kosten über 36 Monate | Standardsoftware | Eigenentwicklung |
|---|---|---|
Einführung oder Entwicklung (einmalig) | 2.000 € | 12.000 € |
Laufende Kosten pro Monat | 820 € | 530 € |
Gesamtkosten nach 36 Monaten | 31.520 € | 31.080 € |
Auf dem Papier liegt die Eigenentwicklung knapp vorn. Wegen 440 Euro Unterschied würde ich allerdings noch keine neue Software umsetzen lassen. Schon ein zusätzlicher Wartungsaufwand könnte das Ergebnis verändern.
Anders sieht es aus, wenn die maßgeschneiderte Lösung konkret den Arbeitsalltag vereinfacht. Angenommen, sie spart gegenüber der Standardsoftware eine Stunde manueller Arbeit pro Woche. Bei einem internen Vollkosten-Stundensatz von 60 Euro ergibt das rund 260 Euro im Monat, über drei Jahre also rund 9.350 Euro. Dieser Vorteil entsteht natürlich nur dann, wenn das Team die gewonnene Zeit tatsächlich produktiv nutzen kann.
Solche Opportunitätskosten werden bei einer Make-or-Buy-Analyse leicht übersehen. Ich rechne deshalb neben den Ausgaben immer den möglichen Nutzen hinzu:
Eingesparte Stunden pro Woche × interner Stundensatz × 4,33 (durchschnittliche Wochen pro Monat)
Vermiedene Fehlerkosten oder wegfallende Lizenzgebühren können den Vorteil zusätzlich erhöhen.
Auch die laufenden KI-Kosten verdienen Aufmerksamkeit. Je nach Modell, Tarif und Nutzungsumfang verändert sich die Rechnung. Schon bei meinem früheren Vergleich der ChatGPT-Versionen war deshalb die Unterscheidung zwischen Leistungsumfang und tatsächlichen Nutzungsmöglichkeiten wichtig.
Ich sehe das letztendlich so: Die günstigere Software ist nicht automatisch die wirtschaftlichere. Es kommt darauf an, was sie über ihre gesamte Anwendungsdauer kostet und welchen messbaren Nutzen sie bringt.
Wann lohnt sich die Eigenentwicklung mit KI-Agenten?
Besonders sinnvoll finde ich eigene Software, wenn ein klar abgegrenzter Prozess regelmäßig erheblichen Aufwand verursacht und Standardlösungen ihn nur umständlich abbilden. KI-Agenten können die Entwicklungskosten dabei deutlich senken. Das macht vor allem kleinere, individuelle Anwendungen wirtschaftlich interessant, für die sich früher kaum ein eigenes Projekt gelohnt hätte.
Eines meiner zentralen Programmierwerkzeuge ist Claude Code. Das Tool kann auf Basis meiner Anweisungen selbstständig Code schreiben, bestehende Dateien bearbeiten und seine Änderungen testen. Dadurch muss ich viele technische Schritte nicht mehr einzeln umsetzen, sondern kann mich stärker darauf konzentrieren, was die Anwendung schließlich leisten soll und wie die einzelnen Abläufe zusammenhängen.
So haben wir bei bakedwith etwa mit Unterstützung von Claude Code unser Airtable durch eine eigene Datenbank auf Basis von Supabase ersetzt. Inzwischen nutzen wir diese als Grundlage für verschiedene interne Anwendungen. Für uns hat sich dieser Schritt gelohnt, weil wir die Datenstruktur und Zugriffsrechte nun nach unseren Anforderungen gestalten können, statt unsere Prozesse immer wieder an die Vorgaben eines externen Tools anzupassen.
Besonders groß ist der Nutzen aus meiner Sicht bei häufig verwendeten internen Werkzeugen mit überschaubarem Funktionsumfang. Das zeigte sich unter anderem in einem Kundenprojekt, bei dem wir ein Lead Lab erstellt haben, das Kontakte anreichert, mithilfe von KI bewertet und an ein CRM übergibt. Für die Realisierung benötigten wir rund zwei Wochen. Ein Telefonie-Cockpit war nach etwa einer Woche startklar. In solchen Fällen braucht es keine umfangreiche Standardsoftware mit zahlreichen ungenutzten Funktionen, sondern eine Anwendung, die eine konkrete Aufgabe zuverlässig übernimmt.
Allerdings sollten die Anforderungen ausreichend klar sein und die nötigen Daten zur Verfügung stehen. Fehlen wichtige Schnittstellen oder müssen erst komplexe Berechtigungsstrukturen aufgebaut werden, kann der Aufwand trotz KI-Unterstützung erheblich steigen. Die genannten Entwicklungszeiten lassen sich deshalb nicht pauschal auf andere Projekte übertragen.
Vibe Coding beschreibt die Programmierung von Software durch natürlichsprachliche Anweisungen an KI, wobei der Code selbst nicht geprüft wird. Für erste Prototypen ist das ausgesprochen hilfreich. Damit daraus eine langfristig zuverlässige und wirtschaftliche Lösung wird, sind allerdings häufig Nacharbeiten am Code, gründliche Tests und eine saubere technische Dokumentation erforderlich.
Welche Tools helfen bei der Eigenentwicklung?
Neben Claude Code gibt es weitere AI-Coding-Assistants wie etwa GitHub Copilot, die beim Schreiben, Überarbeiten und Prüfen von Code helfen. Andere Werkzeuge gehen stärker in Richtung AI-Code-Generation und erstellen auf Basis von Beschreibungen in natürlicher Sprache ganze Programmteile oder erste Anwendungsprototypen.
In meinem Arbeitsalltag nutze ich zusätzlich zu Claude Code unter anderem OpenAIs Codex. Für die technische Grundlage der Programme kommen häufig Supabase als Datenbank und Vercel für die Bereitstellung zum Einsatz. GitHub hilft dabei, Änderungen am Code nachvollziehbar zu verwalten. Das ist wichtig, weil auch KI-generierte Software über längere Zeit gepflegt werden muss.
Sehr hilfreich finde ich Claude Skills. Damit lassen sich wiederkehrende Anweisungen und Arbeitsabläufe hinterlegen. So muss ich dem KI-Agenten bei ähnlichen Aufgaben nicht jedes Mal dieselben Vorgaben erklären.
Nicht jedes Problem braucht jedoch eine selbst erstellte Anwendung. Sollen zum Beispiel Daten zwischen Shopsystem und Warenwirtschaft ausgetauscht werden, kann eine No-Code-Development-Platform zur Schaffung einer effizienten Verbindung die bessere Wahl sein. Bei Synesty lassen sich solche Prozesse etwa per Drag-and-Drop aufbauen, ohne dafür selbst programmieren zu müssen. Statt eine neue Software zu entwickeln, nutzt das Unternehmen also die vorhandenen Systeme und sorgt dafür, dass sie besser zusammenarbeiten.
Solche No-Code- und Low-Code-Werkzeuge sind gerade dann interessant, wenn die bestehenden Systeme grundsätzlich passen und nur ihre Zusammenarbeit verbessert werden muss.
Wann ist Standardsoftware die bessere Wahl?
Wenn es um weitgehend standardisierte Abläufe geht, ist es meiner Erfahrung nach häufig sinnvoll, zuerst fertige Software zu prüfen. Beispielsweise ändern sich rechtliche Vorgaben bei der Buchhaltung regelmäßig. Eine Eigenentwicklung müsste diese Anpassungen selbst nachvollziehen und umsetzen. Ein etablierter Anbieter kann die dafür notwendige Pflege auf viele Kund*innen effizienter verteilen. Für dich ist das meist günstiger.
Handelt es sich zudem um Software as a Service (SaaS), kommt hinzu, dass Unternehmen die Anwendung in der Regel ohne eigene Serverinfrastruktur nutzen. Updates und ein großer Teil des technischen Betriebs liegen beim Anbieter. Gerade für kleinere Teams sind diese Vorteile von SaaS ein wichtiger Grund, sich gegen eine Individualsoftware zu entscheiden.
Allerdings gibt es auch für speziellere Anforderungen längst fertige Lösungen. Möchte ein Unternehmen beispielsweise verschiedene KI-Modelle für interne Aufgaben nutzen und eigene Assistenten einrichten, muss es dafür keine eigene Plattform entwickeln. Genau solche Funktionen bietet etwa innoGPT.
Im Vertrieb bietet amplifa einen anderen Ansatz: Der Dienst übernimmt als Managed Service Teile des B2B-Outbounds, von der Recherche geeigneter Kontakte bis zur Terminvereinbarung. Hoshii wiederum verarbeitet eingehende geschäftliche E-Mails und erstellt aus angebundenen Unternehmensdaten Antwort- oder Auftragsentwürfe zur Freigabe.
Auch der Zeitfaktor spielt eine Rolle. Eine Standardlösung, die morgen einsatzbereit ist, kann viel wirtschaftlicher sein als eine umfangreichere eigene Anwendung, die vielleicht erst in drei Monaten produktiv läuft. Auch Outsourcing an eine Agentur löst diesen Zielkonflikt nicht vollständig. Es nimmt dem Unternehmen zwar einen großen Teil der Entwicklung ab, die Verantwortung für Anforderungen und spätere Änderungen bleibt jedoch bestehen.
Welche Risiken bringt eigene Software mit sich?
Aus meiner Sicht unterschätzen Unternehmen vor allem den Aufwand nach der erfolgreichen Entwicklung. Eine funktionierende Anwendung ist noch kein abgeschlossenes Projekt. Sie benötigt regelmäßige Updates, Backups und jemanden, der bei Problemen schnell und richtig reagieren kann, also eine verantwortliche Person mit dem nötigen Know-how.
Hinzu kommen technische Schulden. Gemeint sind Vereinfachungen oder Abkürzungen bei der Entwicklung, mit oder ohne KI, die spätere Anpassungen erschweren. Gerade mit künstlicher Intelligenz entsteht schnell viel Code. Ohne klare Struktur und ausreichende Tests können daraus Anwendungen werden, die anfangs gut funktionieren, aber zunehmend schwer zu pflegen sind.
Auch die vermeintliche Unabhängigkeit solltest du genau prüfen. Wer Standardsoftware einsetzt, riskiert einen sogenannten Vendor Lock-in: Ein Wechsel des Anbieters kann schwierig oder teuer sein, weil Daten, Schnittstellen und Arbeitsabläufe oft eng mit dem bisherigen Tool verknüpft sind und sich nicht ohne Weiteres auf eine andere Lösung übertragen lassen. Eigene Software beseitigt dieses Risiko allerdings nicht vollständig. Unternehmen können hier ebenso langfristig von einer bestimmten Cloud-Plattform oder Agenturen abhängig sein.
Deshalb achte ich bei meiner Arbeit früh darauf, dass Code und Datenstruktur nachvollziehbar und technisch verständlich dokumentiert sind. So können sich auch andere Entwickler*innen in die Anwendung einarbeiten und sie bei Bedarf übernehmen. Schließlich sollte die Software auf lange Sicht funktionieren, unabhängig davon, wer sie ursprünglich realisiert hat.
Wie triffst du die richtige Make-or-Buy-Entscheidung?
Um herauszufinden, ob sich eigene Software überhaupt lohnt, nutze ich gerne einen einfachen Selbsttest mit zwei Schritten. Zunächst geht es darum, typische Probleme mit den vorhandenen Anwendungen zu erkennen. Anschließend prüfe ich, wie groß der tatsächliche Handlungsbedarf ist und ob eine Eigenentwicklung infrage kommt.
Im ersten Schritt kannst du dich zum Beispiel fragen:
- Müssen Mitarbeiter*innen regelmäßig dieselben Daten manuell in verschiedene Systeme eintragen?
- Fehlen wichtige Funktionen, sodass umständliche Workarounds nötig sind?
- Oder zahlt dein Unternehmen für zahlreiche Softwarefunktionen, die niemand benötigt?
Je mehr solcher Schwierigkeiten bei dir auftreten, desto sinnvoller ist es, die bisherige Lösung zu hinterfragen.
Die Anzahl der Probleme allein ist aber nicht maßgebend. Schau deshalb im zweiten Schritt genauer hin:
- Welche Arbeitsabläufe sind betroffen?
- Wie häufig treten die Schwierigkeiten auf und wie viel Zeit geht dadurch verloren?
Besonders interessant wird es, wenn mehrere Probleme denselben Prozess betreffen. Dann lässt sich oft ein konkreter Ansatzpunkt für Verbesserungen erkennen.
Aus den Antworten ergeben sich für mich drei mögliche Szenarien:
- Wenige, kleinere Probleme: Die vorhandene Standardsoftware reicht wahrscheinlich aus. Einzelne Anpassungen oder eine Automatisierung können genügen.
- Mehrere Probleme in einem bestimmten Ablauf: Hier lohnt es sich, eine eigene Anwendung näher zu prüfen und zunächst einen kleinen Prototyp zu erstellen.
- Viele Probleme in unterschiedlichen Prozessen: Dann würde ich nicht sofort mehrere Tools entwickeln, sondern zuerst die Zusammenhänge und Prioritäten klären. Möglicherweise braucht das Unternehmen eine übergreifende Lösung oder eine bessere Verbindung der vorhandenen Systeme.
Bevor ich zur Eigenentwicklung rate, kläre ich außerdem, ob die benötigten Daten verfügbar sind und wer die Anwendung später betreuen kann. Fehlt dafür intern die Kapazität, muss diese Verantwortung gegebenenfalls extern übernommen werden.
So wird aus einer zunächst allgemeinen Make-or-Buy-Frage eine konkrete Entscheidung. Statt vorschnell Software zu kaufen oder selbst zu programmieren, lässt sich zunächst der Prozess identifizieren, bei dem eine Veränderung den größten Nutzen verspricht.
Fazit: Eigenentwicklung lohnt sich nicht immer
KI-Agenten haben die Make-or-Buy-Entscheidung grundlegend verändert. Eigene Software ist heute für wesentlich mehr Unternehmen realistisch umsetzbar als noch vor wenigen Jahren. Trotzdem bleiben Standardlösungen häufig die bessere Wahl. Ich würde immer dann selbst entwickeln, wenn ein wichtiger Geschäftsprozess dauerhaft unter den Grenzen einer fertigen Lösung leidet und sich der zusätzliche Nutzen nachvollziehbar belegen lässt. Erfahrungsgemäß lassen sich dabei kleine, klar abgegrenzte Vorgänge am wirtschaftlichsten abbilden. Software sollte sich letztlich an die Arbeit anpassen, nicht die Arbeit an die Software, muss dabei aber auch wirtschaftlich vertretbar bleiben.
Werde Gastautor*in: Du hast in einem bestimmten Bereich richtig Ahnung und möchtest dein Wissen teilen? Dann schreibe uns einfach an reviews-experten@omr.com und bring deine Expertise ein. Wir freuen uns auf spannende Einblicke direkt aus der Praxis.
Autor*In
Jens Bohse
Jens Bohse war sechs Jahre bei OMR tätig, zuletzt als Growth Lead, und unterstützte unter anderem den Aufbau von OMR Reviews als eines der ersten Teammitglieder. Nach seiner Zeit bei OMR gründete er die Boutique-Beratung bakedwith, die mittelständische Unternehmen und Konzerne dabei unterstützt, durch smarte Automatisierung und den Einsatz von KI Zeit für das Wesentliche zurückzugewinnen.
