Buy oder Build: wann eine eigene KI-Anwendung sinnvoll ist

Die Frage, ob ein Unternehmen Software kauft oder bauen lässt, ist alt. Neu ist, dass sich die Kosten der zweiten Option stark verändert haben. Anwendungen, deren Entwicklung vor wenigen Jahren Monate und ein sechsstelliges Budget erforderte, entstehen heute mit KI-gestützter Entwicklung in Wochen. Damit verschiebt sich die Grenze, ab der sich eine eigene Anwendung rechnet, deutlich in Richtung kleinerer Vorhaben.

Das bedeutet nicht, dass Bauen immer die bessere Wahl ist. Für viele Aufgaben bleibt Standardsoftware die richtige Antwort. Dieser Leitfaden hilft, die Fälle zu unterscheiden. Er richtet sich an Geschäftsführung, Fachbereichsleitung und IT-Verantwortliche im Mittelstand, die vor einer konkreten Entscheidung stehen.

Die Unterscheidung nach Martin Fowler

Der Softwarearchitekt Martin Fowler hat 2010 vorgeschlagen, Software danach zu unterscheiden, ob die zugrunde liegende Geschäftsfunktion einen Wettbewerbsvorteil darstellt. Für „Utility“-Funktionen, die jedes Unternehmen in ähnlicher Form braucht, etwa Lohnabrechnung oder Buchhaltung, empfiehlt er Standardsoftware und rät, den eigenen Prozess an die Software anzupassen statt umgekehrt. Für „strategische“ Funktionen, mit denen sich ein Unternehmen vom Wettbewerb unterscheidet, empfiehlt er die eigene Entwicklung, weil eine Standardlösung den Unterschied einebnet. Joel Spolsky formulierte bereits 2001 die verwandte Regel, Kernfunktionen des eigenen Geschäfts selbst zu bauen und alles andere zuzukaufen.

Diese Einteilung ist ein guter Ausgangspunkt. Für die Praxis im Mittelstand reicht sie nicht, weil die meisten Vorhaben dazwischen liegen: ein Freigabeprozess, eine Angebotskalkulation, ein Kundenportal. Sie sind nicht strategisch im Sinne eines Alleinstellungsmerkmals, aber so eng mit dem eigenen Ablauf verwoben, dass Standardsoftware nur mit Verrenkungen passt. Für diesen Bereich braucht es genauere Kriterien.

Fünf Kriterien für die Entscheidung

Prozessnähe

Je stärker eine Anwendung den eigenen Ablauf abbilden muss, desto eher spricht das für eine eigene Entwicklung. Standardsoftware bildet den Durchschnitt vieler Unternehmen ab. Stimmt Ihr Prozess mit diesem Durchschnitt überein, ist Standardsoftware günstiger, reifer und besser dokumentiert. Weicht er ab, beginnt die Anpassung: Zusatzfelder, Workarounds, parallele Tabellen, manuelle Übertragungen. Fragen Sie Ihre Fachabteilung, wie viele Schritte des Prozesses außerhalb des heutigen Werkzeugs stattfinden. Ist es mehr als ein Drittel, passt das Werkzeug nicht zum Prozess.

Datenanbindung

Eine Anwendung ist so nützlich wie die Daten, mit denen sie arbeitet. Standardsoftware bringt eigene Datenmodelle mit und bindet Fremdsysteme über Schnittstellen an, die der Hersteller vorsieht. Fehlt die Schnittstelle zu Ihrem ERP, Ihrer Zeiterfassung oder Ihrem Dokumentenarchiv, entstehen Medienbrüche und doppelte Datenhaltung. Eine eigene Anwendung wird um die vorhandenen Datenquellen herum gebaut und liest direkt aus den Systemen, die Sie bereits betreiben. Prüfen Sie für jede Kandidatenlösung, welche Systeme angebunden werden müssen, ob es dafür Schnittstellen gibt und wer sie pflegt.

Lizenzkosten pro Nutzer

Viele Standardprodukte werden pro Nutzer und Monat abgerechnet. Das ist bei wenigen Nutzenden günstig und wird bei vielen teuer, unabhängig davon, wie intensiv der einzelne die Software nutzt. Besonders ungünstig ist das Modell für Anwendungen, auf die möglichst viele Beschäftigte gelegentlich zugreifen sollen, etwa Auswertungen, Freigaben oder ein internes Serviceportal. Rechnen Sie die Lizenzkosten über fünf Jahre und für den Nutzerkreis, den Sie sich wünschen, nicht den, den Sie sich bei diesen Preisen leisten. Eine eigene Anwendung hat einmalige Entwicklungskosten und laufende Kosten für Betrieb und Pflege, aber keine Kosten pro Kopf.

Abhängigkeit

Mit Standardsoftware übernehmen Sie die Entscheidungen des Herstellers: Preisänderungen, Funktionsänderungen, Einstellung von Produkten, Verlagerung des Hostings, Übernahme durch einen anderen Anbieter. Ihre Daten liegen in seinem Datenmodell, der Export ist selten vollständig. Bei einer eigenen Anwendung hängt die Abhängigkeit davon ab, wem der Code gehört und ob andere ihn weiterentwickeln können. Eine Anwendung, deren Quellcode in Ihrem Repository liegt, mit verbreiteten Technologien gebaut ist und deren Dokumentation Ihnen vorliegt, kann jeder qualifizierte Entwickler übernehmen. Eine Anwendung, die nur der ursprüngliche Dienstleister versteht, ist eine Abhängigkeit anderer Art.

Weiterentwicklung

Prozesse ändern sich. Bei Standardsoftware warten Sie auf den Hersteller oder beauftragen Anpassungen innerhalb seiner Grenzen. Bei einer eigenen Anwendung bestimmen Sie den Fahrplan, tragen aber auch die Verantwortung für Pflege, Sicherheitsupdates und Kompatibilität. Klären Sie vor der Entscheidung, wer die Anwendung nach der Übergabe weiterentwickelt: ein internes Team, der ursprüngliche Dienstleister oder ein anderer Entwickler. Mit KI-gestützter Entwicklung können heute auch fachlich versierte Mitarbeitende ohne Entwicklerausbildung kleinere Änderungen vorbereiten; für Architektur, Sicherheit und Qualitätssicherung bleibt Erfahrung erforderlich.

Ein einfaches Bewertungsraster

Bewerten Sie jedes Kriterium mit einem Punkt für Standardsoftware oder für die eigene Anwendung. Das Ergebnis ersetzt keine Wirtschaftlichkeitsrechnung, macht aber die Richtung sichtbar und zwingt zur Diskussion über die Kriterien, bei denen sich die Beteiligten uneins sind.

Kriterium	Spricht für Standardsoftware	Spricht für eigene Anwendung
Prozessnähe	Prozess entspricht dem Branchenüblichen, wenige Sonderfälle	Prozess ist unternehmensspezifisch, viele Schritte laufen heute außerhalb des Werkzeugs
Datenanbindung	Benötigte Schnittstellen sind vorhanden und werden vom Hersteller gepflegt	Mehrere eigene Systeme müssen direkt angebunden werden, Schnittstellen fehlen
Lizenzkosten	Wenige, intensive Nutzende; Kosten über fünf Jahre unter den Entwicklungskosten	Viele gelegentliche Nutzende; Kosten pro Kopf begrenzen die Verbreitung
Abhängigkeit	Hersteller ist etabliert, Datenexport vollständig, Wechsel realistisch	Anwendung berührt Kerndaten oder Kernprozesse, Wechselkosten wären hoch
Weiterentwicklung	Änderungsbedarf gering, Herstellerfahrplan passt	Regelmäßige Anpassungen nötig, Team will selbst gestalten

Vier oder fünf Punkte in einer Spalte ergeben eine klare Empfehlung. Bei zwei zu drei lohnt sich ein genauerer Blick auf das Kriterium mit dem größten finanziellen Gewicht, meist Lizenzkosten oder Anpassungsaufwand.

Typische Fehler

• Den Anpassungsaufwand nicht mitrechnen. Die Lizenz ist nur ein Teil der Kosten von Standardsoftware. Einführung, Anpassung, Schulung, Schnittstellen und die Arbeitszeit für Workarounds gehören in dieselbe Rechnung.
• Alles auf einmal bauen wollen. Eine eigene Anwendung sollte mit dem Ablauf beginnen, der den größten Nutzen hat, und in Betrieb gehen, bevor der nächste folgt. Ein Lastenheft mit dreißig Seiten ist ein Warnsignal.
• Den Eigentümer des Codes nicht klären. Wer eine Anwendung entwickeln lässt, sollte vor Vertragsschluss festlegen, dass Quellcode, Repository, Dokumentation und Zugänge an das Unternehmen übergehen. Ohne diese Regelung ist die eigene Anwendung eine Abhängigkeit mit Einzelanbieter.
• Exotische Technologie wählen. Je seltener die eingesetzte Technologie, desto kleiner der Kreis der Entwickler, die später übernehmen können. Verbreitete Sprachen und Frameworks sind ein Kriterium für Unabhängigkeit.
• Betrieb und Sicherheit vergessen. Hosting, Updates, Zugriffskontrolle, Datensicherung und Datenschutz sind bei einer eigenen Anwendung Ihre Aufgabe oder die eines beauftragten Dienstleisters. Planen Sie sie von Anfang an ein.
• Standardsoftware aus Prinzip ablehnen. Wo der Prozess dem Branchenstandard entspricht, ist Standardsoftware in der Regel die günstigere und sicherere Wahl. Bauen aus Prinzip ist ebenso ein Fehler wie Kaufen aus Prinzip.

So läuft ein Festpreis-Projekt ab

Die klassische Auftragsentwicklung nach Aufwand ist einer der Gründe, warum viele Unternehmen die eigene Anwendung scheuen: Der Umfang wächst, der Termin wandert, die Rechnung folgt. Ein Festpreis-Projekt dreht die Logik um. Der Umfang wird vorher begrenzt, dafür sind Preis und Ergebnis verbindlich. Bei vector zero Build läuft ein Projekt in vier Schritten ab.

1. Scope. Sie beschreiben das Vorhaben: welcher Ablauf gebaut werden soll, wer ihn nutzt und welches Ergebnis am Ende stehen muss. Technische Vorkenntnisse sind nicht erforderlich. Wir liefern Festpreis und Zeitplan für einen definierten Produktstand.
2. Umsetzung. Wir bauen. Sie testen jeden Zwischenstand in einer funktionierenden Preview-Umgebung und geben Rückmeldung an der laufenden Anwendung statt an Dokumenten.
3. Feinschliff. Integrationen zu Ihren Systemen, Rollen und Rechte, Anmeldung, Politur.
4. Übergabe. Go-Live auf Ihrer Domain. Der Code liegt in Ihrem GitHub-Repository; Projektstruktur, Dokumentation, Deployment und Zugänge werden übergeben, Ihr Team wird in die Entwicklungsumgebung eingewiesen. Danach entscheiden Sie, ob Sie selbst weiterentwickeln, einen anderen Entwickler beauftragen oder uns für Wartung und Erweiterungen hinzunehmen.

Die Anwendungen entstehen mit Next.js und TypeScript, mit GitHub für Versionierung und Prüfungen, sodass jeder erfahrene JavaScript- oder TypeScript-Entwickler die Weiterentwicklung übernehmen kann. Der Festpreis funktioniert, weil der Umfang im ersten Schritt klar begrenzt wird. Wünsche, die während der Umsetzung entstehen, werden gesammelt und für einen nächsten Produktstand bewertet, statt den laufenden zu verändern.

Wann Standardsoftware die richtige Antwort bleibt

Buchhaltung, Lohnabrechnung, E-Mail, Office, Videokonferenzen, das führende CRM- oder ERP-System: Für diese Funktionen gibt es ausgereifte Produkte, deren Entwicklung sich für ein einzelnes Unternehmen nicht rechnet und bei denen regulatorische Anforderungen laufend eingepflegt werden müssen. Hier lautet die Empfehlung fast immer Kaufen. Die eigene Anwendung setzt sinnvoll dort an, wo diese Systeme aufhören: bei den Abläufen rund um sie herum, die heute in Tabellen, E-Mails und Nebenwerkzeugen stattfinden.

Auch für die tägliche Arbeit mit Sprachmodellen gilt diese Logik. Ein sicherer KI-Arbeitsplatz mit Anbindung an die eigenen Dokumente ist eine Standardaufgabe, für die es mit der vector zero App ein fertiges Produkt gibt; eine eigene Anwendung lohnt sich erst, wenn ein spezifischer Ablauf mit eigenen Daten, Regeln und Freigaben abgebildet werden soll. Ob Ihr Vorhaben in die eine oder andere Kategorie fällt, klären wir im ersten Gespräch über das Kontaktformular.

Quellen

• Martin Fowler, „UtilityVsStrategicDichotomy“, martinfowler.com, 29. Juli 2010, aktualisiert am 7. April 2016, martinfowler.com
• Joel Spolsky, „In Defense of Not-Invented-Here Syndrome“, Joel on Software, 14. Oktober 2001, joelonsoftware.com
• vector zero Build, Individuelle Softwareentwicklung zum Festpreis, vector zero GmbH, abgerufen am 2. September 2026, vector-zero.de/build