Buy vs. Build für SaaS-KI-Features: Das Entscheidungsframework, das wirklich funktioniert

Die Build-vs.-Buy-Frage existiert in Software seit Jahrzehnten. Die KI-Version dieser Frage sieht oberflächlich ähnlich aus, ist aber strukturell anders auf eine Weise, die die Antwort verändert.

Der Unterschied ist die dritte Option: Wrap.

LLM-APIs (large language model) von OpenAI, Anthropic und Google haben einen Weg geschaffen, der vor 2022 nicht existierte. Sie können KI-Features bauen ohne Modell-Training, ohne ML-Engineers und ohne eine mehrere Millionen Dollar teure Dateninfrastruktur-Investition. Sie rufen eine API auf, übergeben ihr einen gut gestalteten Prompt und Kontext und erhalten intelligente Ausgabe. Es ist keine Magie, aber es ist schnell, und für die meisten SaaS-Produktoberflächen ist es der richtige Ausgangspunkt.

Das klassische Buy-oder-Build-Rahmen verfehlt dies, weil es für eine Ära konzipiert wurde, in der „KI bauen" bedeutete „Data Scientists einstellen und Modelle auf Ihren Daten trainieren". Das ist immer noch eine Option. Es ist nur nicht mehr die einzige. Für die meisten SaaS-Unternehmen unter Series C ist es die falsche.

Die eigentliche Entscheidung ist also dreiseitig: Buy, Wrap oder Build.

Die Buy/Wrap/Build-Entscheidung

Die Buy/Wrap/Build-Entscheidung ist ein dreiseitiges Framework speziell für SaaS-KI-Features. Buy kauft ein dediziertes KI-Vendor-Produkt und integriert es in Ihren Workflow: schnell bereitzustellen, begrenzte Differenzierung, Vendor-Abhängigkeit. Wrap nutzt LLM-APIs direkt, um KI-Features in Ihre eigene Produktoberfläche einzubauen: mittlere Geschwindigkeit, moderate Kosten, signifikante Differenzierung, weil Sie Erfahrung und Kontext kontrollieren. Build trainiert oder fine-tuned eigene Modelle: maximale Differenzierungsdecke, maximale Kosten, maximale Zeit, erfordert ML-Talent. Die meisten SaaS-Unternehmen überspringen Wrap und bewerten nur Buy oder Build. Für die meisten In-Produkt-KI-Features unter 50 Mio. $ ARR ist Wrap der richtige Ausgangspunkt.

Die drei Optionen definieren

Buy: Ein dediziertes KI-Vendor-Produkt kaufen und in Ihren Workflow integrieren. Gong für Sales-Call-Analyse, Gainsight oder Vitally für CS-Health-Scoring, Intercom Fin für Support-Deflection. Schnell bereitzustellen. In Produktion bewährt. Begrenzte Möglichkeit zur Differenzierung.

Wrap: OpenAI-, Anthropic- oder Google-LLM-APIs direkt nutzen, um KI-Features in Ihr eigenes Produkt oder Ihre Operations-Tooling einzubauen. Ihr Code, Ihre UI, deren Modell. Mittlere Baugeschwindigkeit, moderate Kosten bei moderatem Maßstab, signifikantes Differenzierungspotenzial, weil Sie die Erfahrung kontrollieren.

Build: Eigene Modelle trainieren oder fine-tunen. Benutzerdefinierte ML-Pipeline. Proprietäre Trainingsdaten. Maximale Differenzierungsdecke, maximale Kosten, maximale Zeit, erfordert ML-Talent. Reserviert für Fälle, in denen KI wirklich der Kern-Produktunterscheidungsmerkmal ist und Ihre Daten einen Vorteil schaffen.

Die meisten SaaS-Teams, wenn sie sagen „sollten wir KI bauen?", fragen implizit nach Build. Meistens ist die richtige Antwort, mit Wrap zu beginnen und zu sehen, ob Build tatsächlich durch die Daten und die Wettbewerbslandschaft gerechtfertigt ist.

Key Facts: Buy vs. Build Ökonomie in SaaS-KI

• Das Bauen eines mittelkomplexen KI-Agenten von Grund auf dauert mindestens 3-5 Monate; ein Buy- oder Wrap-Ansatz kann Sie in Wochen auf den Markt bringen (Ptolemay LLM TCO Research, 2025)
• 3 von 4 Unternehmen, die versuchen, agentische KI-Architekturen vollständig intern zu bauen, scheitern, weil diese Architekturen ausgefeilte RAG-Stacks, fortschrittliche Datenpipelines und nischen-ML-Expertise erfordern, die die meisten SaaS-Teams vor Stufe 3 nicht haben (Forrester, 2025)
• Durchschnittliche monatliche KI-Ausgaben sprangen von 63.000 \(in 2024 auf 85.500\) in 2025, ein Anstieg von 36 %, wobei der Anteil der Unternehmen, die planen, über 100.000 $ pro Monat für KI auszugeben, sich im gleichen Zeitraum mehr als verdoppelt hat (Binadox, 2025)

Wann man kauft (Buy)

Kaufen ist die richtige Antwort, wenn der Use Case gut verstanden, von bestehenden Anbietern gut bedient wird und Time-to-Value wichtiger ist als Differenzierung.

Sales-Call-Analyse ist für die meisten SaaS-Unternehmen ein Buy-Use-Case. Gong verfeinert KI-Call-Scoring seit Jahren, hat Modelle auf Millionen von Sales-Calls trainiert und integriert sich mit jedem großen CRM. Ihren eigenen Call-Analyse-KI zu bauen macht Sie nicht wettbewerbsfähiger; es verzögert nur die Wertrealisierung, während Sie etwas neu erfinden, das bereits funktioniert. Buy vs. build by pattern bildet diese Entscheidung über jedes ACE-Muster hinweg ab.

Support-Deflection via KI-Chatbot ist ähnlich. Intercom Fin, Zendesk AI und ähnliche Produkte haben starke Modelle, die für Support-Resolution abgestimmt sind. Ihre KI verbessert sich durch die Support-Interaktionen jedes Kunden, nicht nur Ihrer.

Die Regel: Kaufen Sie, wenn der Use Case standardisiert ist, der Vendor echte Trainingsdatenvorteile gegenüber einem frischen LLM-API-Aufruf hat und Differenzierung in diesem Use Case keine Kundenentscheidungen treibt.

Ihre Kunden wählen Ihr SaaS-Produkt nicht, weil Ihr Support-Chatbot eine einzigartige Persönlichkeit hat. Kaufen Sie die Support-KI, investieren Sie Ihre KI-Engineering-Zeit dort, wo es wichtig ist.

Das Kostenprofil beim Kaufen: 15.000-80.000 $ pro Jahr pro Tool für Mid-Market-SaaS. Die Buy-Entscheidung bei 10 Tools ist eine bedeutende Budgetlinie. Aber sie ist vorhersehbar und erfordert keine Engineering-Headcount zur Wartung.

Wann man wrappt (Wrap)

Wrapping ist richtig, wenn Sie KI in Ihrer eigenen Produktoberfläche benötigen, der Use Case spezifisch genug ist, dass generische Vendor-Tools nicht passen, und Sie noch nicht genug proprietäre Daten haben, um das Training eigener Modelle zu rechtfertigen.

In-Produkt-KI-Copilots sind der kanonische Wrap-Use-Case. Wenn Ihr SaaS ein Projektmanagement-Tool ist und Sie einen KI-Assistenten hinzufügen möchten, der Nutzern beim Entwurf von Aufgabenbeschreibungen hilft, Abhängigkeiten automatisch vorschlägt und den Projektstatus für Stakeholder zusammenfasst, gibt es keinen Vendor, der genau das für Ihr Datenmodell macht. Sie müssen es bauen, aber Sie müssen kein Modell trainieren. Sie wrappen eine LLM-API: übergeben ihr Kontext aus Ihrer Datenbank, gestalten den Prompt sorgfältig, verarbeiten die Ausgabe in Ihrer UI. KI-Copilots in der SaaS-Produkt-UI behandelt die Produktdesign-Entscheidungen, die der Build/Wrap-Wahl folgen.

Wrapping ist auch richtig für KI-Features in Workflows, die spezifisch für den Use Case Ihres Produkts sind. Wenn Ihr SaaS-Tool eine Rechtsplattform ist und Sie KI zur Kennzeichnung potenziell problematischer Vertragsklauseln hinzufügen möchten, müssen Sie kein Modell auf Vertragsrecht trainieren. Sie wrappen Claude oder GPT-4 mit einem gut gestalteten System-Prompt, der Ihr Klausel-Evaluierungsframework enthält. Version 1 wird in Wochen geshippt, nicht Monaten.

Die Regel: Wrappen Sie, wenn das Feature den Kontext Ihres Produkts erfordert, kein Vendor eine fertige Lösung hat, die passt, und Ihr Team weder die ML-Expertise noch die Daten hat, um eigene Modelle zu bauen.

Das Kostenprofil beim Wrapping: Hier werden Teams überrascht. LLM-API-Preisgestaltung bei geringer Nutzung ist trivial. Bei Skalierung nicht.

OpenAIs GPT-4o bei 2,50 \(pro Million Input-Token und 10\) pro Million Output-Token klingt günstig. Rechnen Sie es für 10.000 MAUs (monatlich aktive Nutzer), die jeweils 20 KI-Vervollständigungen pro Monat auslösen, mit durchschnittlich 2.000 Input-Token und 500 Output-Token pro Aufruf:

• Monatlicher Input: 10.000 x 20 x 2.000 = 400M Token x 2,50 $/M = 1.000 $
• Monatlicher Output: 10.000 x 20 x 500 = 100M Token x 10 $/M = 1.000 $
• Monatliche LLM-Kosten: 2.000 $

Das ist handhabbar. Aber wenn 100 Power-User 500 Vervollständigungen statt 20 ausführen und ihre Prompts 5.000 Token mit 2.000 Token Output haben:

• Monatlicher Input: 100 x 500 x 5.000 = 250M Token x 2,50 $/M = 625 $
• Monatlicher Output: 100 x 500 x 2.000 = 100M Token x 10 $/M = 1.000 $

Immer noch handhabbar. Das eigentliche Risiko entsteht, wenn Sie Ihr KI-Feature pauschal (ohne Nutzungslimits) bepreist haben und den 95. Perzentil-Nutzer nicht modelliert haben. Ein einzelner Enterprise-Kunde mit 200 aktiven Nutzern, die jeweils 100 Vervollständigungen täglich ausführen, kann Sie 40.000-60.000 $ pro Monat an API-Kosten kosten, wenn Sie keine Verbrauchsbeschränkungen eingebaut haben.

Wrapping erfordert von Anfang an eine Verbrauchsarchitektur. Rate-Limits pro Nutzer, Nutzungsdashboards und Verbrauchsobergrenzen bei Pauschaltarifen sind keine optionalen Features, die später hinzugefügt werden.

Anthropics und Googles Preisgestaltung folgt ähnlichen Mustern, mit Claude 3.5 Sonnet bei 3 $/M Input und 15 $/M Output ab 2026. Die Kalkulation ändert sich durch die Modellwahl nicht wesentlich. Die Architekturanforderung ist dieselbe.

Wann man wirklich baut (Build)

Das Bauen eigener Modelle ist gerechtfertigt, wenn drei Bedingungen gleichzeitig wahr sind:

1. Ihre Daten schaffen einen verteidigbaren Vorteil, den ein Vendor mit seinen generischen Trainingsdaten nicht replizieren kann
2. Das KI-Feature ist für die Differenzierung Ihres Produkts zentral (Kunden wählen Sie teilweise deswegen)
3. Ihr Unternehmen hat ML-Engineering-Talent oder kann es sich leisten

Wenn eine dieser drei Bedingungen falsch ist, dient Ihnen Wrapping besser.

Die SaaS-Datenvorteil-Bedingung ist die wichtigste. Wenn Ihr Produkt einzigartige Verhaltensdaten in großem Maßstab generiert, sind diese Daten ein Asset für das Modell-Training. GitHub hatte das für Code-Vervollständigung: die Code-Repositories von Millionen von Entwicklern, jeweils mit Commit-History, Code-Review-Feedback und Autorschaft-Kontext. Kein Wettbewerber konnte diesen Datensatz kaufen. Copilots Qualität ist zum Teil eine Funktion von GitHubs einzigartiger Datenposition.

Die meisten SaaS-Unternehmen haben diesen Vorteil bei Series A oder B nicht. Sie haben 500-5.000 Kunden. Ihre Daten sind wertvoll für Prompt-Design und RAG-Retrieval, sind aber nicht groß oder einzigartig genug, um ein fine-getuntes Modell gegenüber einem gut-geprompteten Basismodell bedeutend zu verbessern. Vor dem Bestehen des Datenvorteils zu bauen verbrennt Engineering-Ressourcen, um schlechtere Ergebnisse als Wrapping zu erzielen.

Die Regel: Bauen Sie, wenn Ihre proprietären Daten im Maßstab Modellqualität erzeugen, die Wrapping nicht replizieren kann, und wenn diese Qualität der Grund ist, warum Kunden Sie bezahlen.

Das Kostenprofil beim Bauen: Modell-Training-Runs kosten 50.000-500.000 \(oder mehr für bedeutende Fine-Tuning. ML-Engineer-Gehälter in 2026 sind 200.000-350.000\) vollständig belastet. Produktions-Inferenz-Infrastruktur kostet 10.000-50.000 $ pro Monat im SaaS-Maßstab. Dazu kommen 6-12 Monate Zeit bis zur Produktion und die Opportunitätskosten für nicht geshippt Produktfeatures in dieser Zeit. Forresters Analyse von Build vs. Buy im KI-Zeitalter stellt fest, dass 3 von 4 Unternehmen, die versuchen, agentische KI-Architekturen vollständig intern zu bauen, scheitern.

Unter 20 Mio. \(ARR ist diese Kostenstruktur schwer zu rechtfertigen, es sei denn, KI ist buchstäblich das Produkt. Über 50 Mio.\) ARR mit starken Datenvorteil-Belegen kann es die richtige Investition sein.

Die versteckten Risiken, die Sie einpreisen müssen

Jede Option hat Kosten, die nicht in der anfänglichen Budgetschätzung erscheinen.

Die versteckten Kosten beim Kaufen: Vendor-Abhängigkeit. Wenn Gainsight ihr Preismodell ändert (das passiert), ändert sich Ihr CS-Operations-Budget ohne Ihre Beteiligung. Wenn Gong ein Feature verwirft, um das Sie einen Workflow gebaut haben, bauen Sie den Workflow neu. Wichtiger: Die KI-Verbesserung kumuliert im Modell des Vendors, nicht in Ihrem. Jeder Sales-Call, den Sie durch Gong verarbeiten, trainiert Gongs Modell, nicht Ihres. Sie machen ihr Produkt besser. In Reifestufe 4 ist das wichtig, weil sich Ihr Datenvorteil nicht aufbaut, wenn Sie kaufen. AI vendor lock-in mitigation strategies behandelt den Schutz von Flexibilität auch innerhalb von Buy-Entscheidungen.

Die versteckten Kosten beim Wrapping: Modell-Deprecation. OpenAI hat GPT-4 32k und mehrere andere Modelle mit 6-12 Monaten Vorankündigung eingestellt. Wenn Ihre Wrapping-Architektur eng mit einer bestimmten Modellversion gekoppelt ist, ist die Migration ein bedeutendes Engineering-Projekt. Die richtige Architektur wrappt das Modell hinter einer Abstraktionsschicht, damit Sie zugrunde liegende Modelle austauschen können, ohne Ihren KI-Feature-Code neu zu schreiben.

Die versteckten Kosten beim Bauen: Es sind nicht nur die Anfangskosten. Modelle brauchen Wartung. Datenpipelines brauchen Monitoring. Modell-Performance verschlechtert sich, wenn sich die Welt ändert und die Trainingsdaten veralten. Das Team, das Sie einstellen, um das ursprüngliche Modell zu bauen, ist jetzt das Team, das für dessen Wartung, Monitoring und Umtraining verantwortlich ist. Das sind laufende Betriebskosten, die die Buy- und Wrap-Optionen nicht auferlegen.

„Die Unternehmen, die direkt zu Build in Stufe 1 springen, geben 800.000 \(für ML-Engineering aus und enden mit einem schlechteren Copilot, als ein 200\)/Monat Anthropic-API-Abonnement erzeugt hätte. Kaufen Sie die GTM-KI-Tools. Wrappen Sie die LLM-APIs für Produkt-KI. Reservieren Sie Build für proprietäre Datenvorteil-Use-Cases." (Rework Analysis, 2025)

„Modell-Deprecation ist die versteckte Wrap-Kosten, für die Teams nicht budgetieren. OpenAI hat GPT-4 32k und mehrere andere Modelle mit 6-12 Monaten Vorankündigung eingestellt. Wenn die Wrapping-Architektur eng mit einer bestimmten Modellversion gekoppelt ist, ist die Migration ein bedeutendes Engineering-Projekt. Die richtige Architektur wrappt das Modell hinter einer Abstraktionsschicht." (Rework Analysis, 2025)

Buy vs. Wrap vs. Build: Entscheidungsmatrix

Quellen: Forrester Build vs. Buy in the Age of AI 2025, Ptolemay LLM TCO Research 2025, Vendasta Build vs. Buy AI Analysis 2026

Rework Analysis: Der teuerste Fehler in SaaS-KI-Investitionen ist das Bauen eigener Modelle, bevor der Datenvorteil existiert. Die meisten Series-A-B-Unternehmen haben 500-5.000 Kunden. Ihre Daten sind wertvoll für Prompt-Design und RAG-Retrieval, sind aber nicht groß oder einzigartig genug, um ein fine-getuntes Modell gegenüber einem gut-geprompteten Basismodell bedeutend zu verbessern. Teams, die Build evaluieren, bevor sie alle drei Bedingungen bestätigt haben (verteidigbarer Datenvorteil, zentrales Produkt-Unterscheidungsmerkmal, ML-Talent verfügbar), verbrennen Engineering-Kapital für schlechtere Ergebnisse als Wrapping erzeugen würde.

Ein Entscheidungsframework für die Wahl

Die einfachste Version ist ein Zwei-Fragen-Test:

1. Erfordert dieses KI-Feature den spezifischen Kontext und die Daten Ihres Unternehmens, um bedeutend besser als eine generische Vendor-Lösung zu sein?
2. Ist dieses KI-Feature etwas, wofür Kunden ausdrücklich Ihr Produkt wählen, im Gegensatz zu einem unterstützenden Feature, das sie schätzen, aber nicht gegen Alternativen bewerten?

Wenn die Antwort auf Frage 1 Nein ist: Buy. Wenn die Antwort auf Frage 1 Ja und Frage 2 Nein ist: Wrap. Wenn die Antwort auf beide Ja ist und Sie die Daten und das Talent haben: Build.

Angewendet auf spezifische Szenarien:

Das Framework sagt Ihnen, welche Wahl zu treffen ist. Sequenzierung sagt Ihnen, wann.

Die Sequenzierung, die in der Praxis funktioniert

Für die meisten SaaS-Unternehmen in Reifestufe 2-3:

1. Kaufen Sie die GTM-KI-Tools (Gong, Gainsight, Intercom AI) in den ersten 6 Monaten. Sammeln Sie Daten darüber, wie gute KI-unterstützte Ergebnisse in Ihrem Kontext aussehen.
2. Wrappen Sie LLM-APIs für Ihre In-Produkt-KI-Features ab Stufe 2. Warten Sie nicht bis Stufe 4, um KI zu Ihrem Produkt hinzuzufügen.
3. Evaluieren Sie Build in Stufe 4, wenn Sie 18-24 Monate Nutzerverhaltensdaten haben, eine klare Datenvorteil-Hypothese und ARR, der ML-Headcount unterstützt.

Die Unternehmen, die direkt zu Build in Stufe 1 springen, sind die, die 800.000 \(für ML-Engineering ausgeben und mit einem schlechteren Copilot enden, als ein 200\)/Monat Anthropic-API-Abonnement erzeugt hätte.

Standard Buy für GTM-KI. Standard Wrap für Produkt-KI. Reservieren Sie Build für Ihre proprietären Datenvorteil-Use-Cases. Dann überdenken Sie, wenn Ihre Daten akkumulieren.

---

Mehr erfahren:

• Buy vs. Build by Pattern: die Entscheidung über jedes ACE-Muster hinweg
• Build vs. Buy vs. Integrate Decision: das Strategie-Level-Entscheidungsframework für KI-Infrastruktur
• AI Vendor Lock-In Mitigation Strategies: Schutz der Flexibilität innerhalb von Buy-Entscheidungen
• Die SaaS-KI-Reifegrade: wie Buy/Wrap/Build-Entscheidungen sich über Stufen verschieben
• KI-Copilots in der SaaS-Produkt-UI: Produktdesign-Entscheidungen, die einer Wrap-Wahl folgen
• Der KI-Wettlauf im SaaS: Speed to Ship: Wettbewerbs-Timing-Kontext für die Build/Buy-Entscheidung