Enterprise-Software selbst entwickeln oder kaufen: Der herstellerneutrale Entscheidungsrahmen (mit 12-Punkte-Bewertungsmatrix, 2026)

Enterprise-Software selbst entwickeln oder kaufen: Der herstellerneutrale Entscheidungsrahmen (mit 12-Punkte-Bewertungsmatrix, 2026)

Letzten September stellte uns ein B2B-SaaS-Unternehmen mit $50M ARR eine Frage, die Unternehmen Millionen kosten kann, wenn sie falsch beantwortet wird: Den bestehenden Salesforce + Tableau + Outreach-Stack für $487K über die nächsten fünf Jahre weiternutzen — oder eine eigene Revenue-Ops-Plattform für $312K bauen? Die "günstigere" Antwort war die falsche. Hier ist das Framework, mit dem wir das herausgefunden haben: eine 12-Punkte-Bewertungsmatrix, ein 5-Jahres-TCO-Modell und Gartners Buy/Build/Blend-Dreiteilung, die kein einziges der aktuell auf Google gelisteten Top-10-Ergebnisse zu diesem Thema erwähnt. Und ja — wir sind eine Engineering-Agentur, also erklären wir Ihnen auch, wann Sie SaaS kaufen sollten, anstatt uns zu beauftragen.

Die wichtigsten Erkenntnisse (TL;DR):

• Die meisten Ratgeber zum Thema kaufen-oder-entwickeln kommen von Anbietern, die von einer Antwort profitieren. Prüfen Sie die Interessen Ihrer Quellen, bevor Sie ihnen vertrauen.
• Gartners Buy/Build/Blend-Framework deckt heute 76 % der Enterprise-Software-Ausgaben ab. Reines Kaufen oder reines Entwickeln ist 2026 der Sonderfall, nicht die Regel.
• Treffen Sie die Entscheidung anhand von 12 gewichteten Kriterien, nicht nach Bauchgefühl. Individuelle Entwicklung gewinnt ab einem Gesamtscore von >45; SaaS gewinnt unter 30.
• KI-Coding-Agenten (Cursor, Claude Code) reduzieren den Senior-Engineering-Aufwand pro Feature um 40–60 % (Stand 2026). Die Entwicklungsrechnung hat sich verändert.

Was ist die "kaufen oder entwickeln"-Entscheidung bei Enterprise-Software?

Die Kaufen-oder-Entwickeln-Entscheidung ist die Wahl zwischen dem Lizenzieren bestehender SaaS- oder COTS-Software (kaufen), der individuellen Eigenentwicklung (bauen) oder der Beauftragung einer Partneragentur für eine proprietäre Softwarelösung (auslagern). Gartners modernes Konzept erweitert dies zu Buy/Build/Blend — und heute fließen 76 % der Enterprise-Software-Ausgaben in Kombinationen aus Standardprodukten und individuellen Erweiterungen, nicht in reine Einzel- oder Kauflösungen.

Die Entscheidung hängt von drei Fragen ab:

• Ist diese Fähigkeit ein Wettbewerbsvorteil oder eine Standardleistung?
• Wie hoch sind die echten 5-Jahres-Gesamtkosten (TCO) jedes Wegs?
• Können Sie dauerhaft ein erfahrenes Engineering-Team aufbauen, das die Lösung langfristig verantwortet?

Transparenzhinweis: Techsy ist eine Engineering-Agentur. Wir verdienen Geld, wenn Sie entwickeln lassen. Deshalb nennen wir Ihnen genau die Situationen, in denen Sie besser SaaS kaufen sollten — und uns nicht beauftragen. Langfristig funktionieren solche Beiträge nur, wenn die Zahlen ehrlich sind. Unser kommerzielles Ziel ist am Ende dieses Artikels genannt; alles dazwischen ist das Framework, nicht die Werbebotschaft.

Die meisten Ratgeber zu diesem Thema werden von Leuten geschrieben, die von einer der beiden Antworten profitieren. SaaS-Marktplätze wollen, dass Sie kaufen. Entwicklungsagenturen wollen, dass Sie bauen. COTS-Anbieter wollen, was ihre Verlängerung sichert. Lesen Sie drei solcher Ratgeber, und Sie bekommen drei selbstsichere, gegensätzliche Empfehlungen — jede unter einem Verkaufshaken begraben. Falls Sie konkret eine Voice-KI-Entscheidung bewerten, haben wir eine vertikale Version dieses Frameworks speziell dafür verfasst. Der Rest dieses Beitrags ist das allgemeine Beschaffungs-Framework, das Sie tatsächlich in einem Meeting einsetzen können.

Was Gartner wirklich sagt: Das Buy / Build / Blend Framework

Gartners Beschaffungsframework lehnt die binäre Kaufen-oder-Entwickeln-Frage ab und ersetzt sie durch eine dreigliedrige Entscheidung: Kaufen (COTS- oder SaaS-Lizenz), Entwickeln (individuelle Eigenentwicklung) oder Kombinieren (SaaS für Standardprozesse, eigener Code für differenzierte Prozesse). Laut dem Gartner Buy/Build/Blend-Modell fließen 76 % der Enterprise-Software-Ausgaben in kombinierte Stacks. Rein kaufen oder rein entwickeln ist die Ausnahme.

Kaufen = Lizenzieren, was bereits gelöst ist

Kaufen, wenn die Fähigkeit ein gelöstes Problem ist und jemand anderes die Lösung bereits in großem Maßstab betreibt. CRM, Lohnbuchhaltung, E-Mail, Spesenmanagement, Observability. Die Wirtschaftlichkeit des Kaufens ist am besten, wenn Sie weniger als 100 Nutzer auf dem Workflow haben, die Lösung in unter 90 Tagen live sein muss und die SaaS mehr als 80 % Ihres Bedarfs abdeckt.

Entwickeln = Besitzen, was Sie unterscheidet

Entwickeln, wenn die Fähigkeit Ihr Wettbewerbsvorteil ist. Das, wofür Kunden Sie wählen. Stripe hat keinen Zahlungsstack lizenziert. Figma hat keine Rendering-Engine lizenziert. Entwickeln gewinnt auch, wenn SaaS Ihre Datenstruktur schlicht nicht abbilden kann (etwa komplexe Mehreinheiten-Finanzmodelle oder ungewöhnliche Compliance-Anforderungen) oder wenn Ihre 5-Jahres-SaaS-Kosten bei Ihrer Nutzergröße die Entwicklungskosten um das Doppelte oder mehr übersteigen.

Kombinieren = Die Rechnung, bei der die meisten Unternehmen landen

Kombinieren bedeutet: COTS für die langweiligen 80 % beibehalten und individuell für die differenzierten 20 % entwickeln. Das klassische Muster: Salesforce als System of Record + eine dünne individuelle Schicht für Workflows, die Salesforce nicht sauber abbilden kann. Thoughtworks nennt das Buy/Build/Partner; Gartner nennt es Buy/Build/Blend. Gleiche Idee, leicht unterschiedliche Begriffe. Die Dreiteilung geht auf McKinseys Make-or-Buy-Matrix aus den 1990er Jahren zurück, doch die Cloud-Ära hat die dritte Option zur dominierenden gemacht.

Die 12-Punkte-Bewertungsmatrix (In eine Tabellenkalkulation kopieren)

Bewerten Sie jedes Kriterium mit 1–5, je nachdem wie stark es auf Ihre Situation zutrifft. Multiplizieren Sie mit dem Gewicht. Addieren Sie die Summen. Die Schwellenwert-Legende unten zeigt, auf welchen Weg die Zahlen hinweisen. Setzen Sie diese Matrix in einem echten Beschaffungs-Meeting ein, und Sie kürzen die Diskussion von zwei Stunden auf zwanzig Minuten.

Schwellenwert-Legende:

• Gesamtscore <30 → SaaS kaufen
• Gesamtscore 30–45 → Kombinieren
• Gesamtscore >45 → Selbst entwickeln

Praxisbeispiel mit unserem Fallstudien-Kunden (den wir in H2 #8 ausführlich besprechen): Er erzielte 38 Punkte. Der Wettbewerbsvorteil lag bei 3 (Revenue Ops ist wichtig, aber nicht der Kernvorteil), die Engineering-Kapazität bei 2 (keine langfristige Ingenieursbindung möglich), die SaaS-Abdeckungslücke bei 4 (Salesforce deckte etwa ein Drittel der Workflows nicht ab), die KI-Kostensenkung bei 5. Ergebnis: klar im Kombinieren-Bereich — und genau dort landete die Empfehlung.

Ein Vorbehalt: Die Matrix ist eine Entscheidungshilfe, kein Entscheidungsträger. Liegt Ihr Gesamtscore im Grenzbereich (28–32 oder 43–47), führen Sie zuerst das TCO-Modell im nächsten Abschnitt durch. Zahlen verändern die Einschätzung.

TCO-Modellierung: Wie Sie 5-Jahres-Kosten ehrlich berechnen

Laut Gartner-Forschung zur Software-Kostenanalyse übersehen Unternehmen 50–70 % der TCO bei der Berechnung von Softwarekosten. Die am häufigsten vergessenen Posten: Integration, Verwaltungs-FTE und Ausstiegskosten. Der Listenpreis im ersten Jahr ist der kleinste Teil der Rechnung — und fast jede Anbieter-Demo zeigt genau diese Zahl.

So berechnen Sie die 5-Jahres-TCO ehrlich für jeden Weg.

Kaufen (SaaS) — Kostenposten: Lizenzgebühren × Nutzer × Jahre, Implementierung und Einrichtung, Schulungen, Verwaltungs-FTE-Zuweisung (typischerweise 0,5–2 FTE in Enterprise-Umgebungen), Integration in bestehende Systeme und Ausstiegskosten beim späteren Wechsel.

Entwickeln (Individuallösung) — Kostenposten: Engineering-Aufwand (Ingenieursmonate × vollständig kalkulierter Stundensatz), Wartung pro Jahr (Faustformel der Branche: 15–20 % der ursprünglichen Entwicklungskosten), Infrastruktur und Werkzeuge sowie Opportunitätskosten für die gebundene Engineering-Kapazität.

Kombinieren — Kostenposten: SaaS-Abonnement für die Standardschicht plus individuelle Integrations- und Erweiterungskosten plus Wartung der individuellen Schicht. Geringerer Anfangsaufwand als reine Eigenentwicklung, geringere laufende Kosten als vollständiger SaaS-Kauf.

Nutzen Sie $230K als vollständig kalkulierten Jahresstundensatz eines US-Küsten-Ingenieurs: Der BLS-Median lag im Mai 2024 bei $130.160, zuzüglich ~30 % Sozialleistungen und ~25 % Gemeinkosten. Anpassen ±30 % je nach Standort. Europäische Teams liegen typischerweise 20–30 % niedriger; US-Teams außerhalb der Küstenregionen 15–20 % niedriger.

Generische Richtwerte. Ihre Zahlen werden abweichen; die Kostenposten nicht.

Wann man KOMBINIEREN sollte (Der mittlere Weg, bei dem die meisten Unternehmen landen)

Kombinieren gewinnt, wenn weder reines Kaufen noch reines Entwickeln sauber auf Ihren Workflow passt. Sie behalten COTS für Standardschichten (CRM, Abrechnung, Identität, Observability) und entwickeln individuell für Workflows, die entweder Ihr Wettbewerbsvorteil sind oder sich in der SaaS schlicht nicht abbilden lassen. Das Bindeglied dazwischen sind APIs, MCP-Server oder Low-Code-Workflow-Engines.

Vier konkrete Kombinationsmuster, die wir regelmäßig sehen:

1. Salesforce + individuelle RevOps-Schicht. Salesforce bleibt als System of Record. Die individuelle Schicht übernimmt die mehrstufigen Revenue-Workflows, die Salesforces Process Builder nicht sauber abbilden kann. Die folgende Fallstudie ist genau dieses Muster.
2. SAP/NetSuite + individuelle Datenschicht. Das ERP für Buchhaltung und Beschaffung behalten. Ein Data Warehouse plus individuelle Dashboards für die Finanzanalysen, die der CFO tatsächlich braucht.
3. HubSpot + individuelle Anreicherungspipeline. HubSpot für Sequencing und CRM nutzen, aber eine eigene Anreicherung entwickeln, wenn kommerzielle Datenanbieter für Ihr ICP nicht präzise genug sind.
4. COTS-HR + individuelle Workflow-Automatisierung. BambooHR oder Rippling für die Datenhaltung, n8n oder individueller Code für die Onboarding- und Offboarding-Orchestrierung, die kein Anbieter vernünftig paketiert.

Das Kombinieren wurde 2026 spürbar günstiger, weil KI-Features schrittweise in eine bestehende SaaS zu integrieren kein Forschungsteam mehr erfordert und MCP-Server, die SaaS und individuellem Code verbinden, die Integrationskosten senken, die Kombinationslösungen historisch teuer gemacht haben. Kombinieren ist kein Kompromiss. Es ist die Antwort für 76 % der Unternehmen, laut Gartner.

Wann man ENTWICKELN sollte (3 Szenarien, in denen individuelle Entwicklung gewinnt)

Eigenentwicklung gewinnt in drei klaren Szenarien. Trifft keines davon auf Ihre Situation zu, sollten Sie wahrscheinlich nicht selbst entwickeln.

1. Die Fähigkeit ist Ihr Wettbewerbsvorteil

Wenn Kunden Sie genau wegen dieser Fähigkeit wählen, können Sie sie nicht von einem Anbieter lizenzieren, dessen andere Kunden Ihre Wettbewerber sind. Stripe hat keinen Zahlungsstack lizenziert. Notion hat keine Dokumenten-Engine lizenziert. Die Fähigkeit muss der Burggraben sein, nicht bloß ein Feature, das Sie zufällig nutzen.

2. SaaS kann Ihre einzigartige Datenstruktur nicht abbilden

Wenn Ihre Daten eine Struktur haben, die bestehende SaaS schlicht nicht darstellen kann (komplexe Mehreinheiten-Finanzmodelle, ungewöhnliche regulatorische Schemata, Echtzeit-Multiplayer-Zustände), geben Sie mehr für Anpassungsgebühren und Beraterstunden aus, als eine Eigenentwicklung kosten würde. Testen Sie das, indem Sie zwei SaaS-Anbieter für ein bezahltes Proof-of-Concept gewinnen. Scheitern beide, entwickeln Sie.

3. 5-Jahres-SaaS-TCO übersteigt individuelle Entwicklung um das 2-Fache oder mehr

Die Rechnung dreht sich mit der Nutzerzahl. 500 Nutzer auf einer $200/Platz/Monat-SaaS = $1,2M/Jahr = $6M über 5 Jahre. Eine fokussierte Eigenentwicklung für denselben Workflow könnte bei $400K Aufwand plus $80K/Jahr Wartung = $800K über 5 Jahre landen. Sobald der Faktor 2x oder mehr beträgt und der Workflow stabil ist, entwickeln Sie.

Ehrlicher Risikohinweis: Selbst entwickeln bedeutet, Projektrisiken zu tragen. Der Standish Group CHAOS Report zeigt, dass 69 % der IT-Projekte teilweise oder vollständig scheitern. Entwickeln ist auch dann nicht kostenlos, wenn die Zahlen es nahelegen. Begrenzen Sie das Risiko durch Scope-Disziplin, echtes Product-Ownership und ein frühes MVP. Bei internem KI-Tooling speziell ist selbst gehostete Enterprise-KI-Software ein Entwicklungsmuster, das 2026 funktioniert, wo die Standardprodukte Datenanforderungen nicht erfüllen.

Wann man KAUFEN sollte (und die versteckten Kosten, über die niemand spricht)

Kaufen gewinnt, wenn die Fähigkeit ein Standard ist, Sie sie schnell benötigen und SaaS den Großteil Ihres Bedarfs abdeckt. Drei Szenarien:

1. Die Fähigkeit ist eine Standardleistung

CRM, E-Mail, Buchhaltung, Observability, Identität, Spesenmanagement. Das sind gelöste Probleme. Die SaaS-Anbieter haben tausende Randfälle bereits abgearbeitet, auf die Sie sonst selbst stoßen würden. Diese Bereiche 2026 von Grund auf selbst zu entwickeln ist fast immer falsch.

2. Sie brauchen die Lösung in <90 Tagen live

Wenn der Workflow Umsatz blockiert und Sie keine Engineering-Kapazität entbehren können, kaufen Sie. Die Opportunitätskosten eines 6-monatigen Entwicklungsprojekts gegenüber einer 6-wöchigen SaaS-Einführung übersteigen fast immer die Lizenzgebühr.

3. SaaS löst >80 % sofort

Wenn die Anpassungskosten für die verbleibenden 20 % geringer sind als die gesamte SaaS-Prämie, kaufen Sie einfach. Prüfen Sie das, indem Sie die Lücken vor der Unterschrift auflisten. Sind die Lücken workflow-leicht (Einstellungen, Integrationen, einfaches Reporting), ist es in Ordnung. Sind sie workflow-intensiv, nicht.

Die versteckten Kosten, die in keiner Anbieter-Demo auftauchen:

SaaS-Preise steigen schleichend. Der Zylo 2025 SaaS Management Index zeigt, dass ein durchschnittliches Unternehmen pro Jahr rund $21M für ungenutzte oder doppelt gebuchte SaaS-Plätze verschwendet. Die Lizenzgebühr ist der erste Kostenposten, nicht der gesamte.

Fallstudie: Wir halfen einem $50M-SaaS-Unternehmen bei der Entscheidung — $487K Salesforce-Stack vs. $312K Individualentwicklung

In Q3 2025 fragte uns ein $50M-ARR-B2B-SaaS-Unternehmen, ob es seinen bestehenden Salesforce + Tableau + Outreach-Stack (geschätzte 5-Jahres-TCO: $487K) erweitern oder eine eigene Revenue-Ops-Plattform auf Next.js + Postgres + eigener Pipeline-Tooling (geschätzte 5-Jahres-TCO: $312K) bauen sollte. Hier sind die genauen Zahlen, die wir gemeinsam durchgearbeitet haben, warum die „günstigere" Option $312K für den Kunden die falsche war und was letztlich umgesetzt wurde.

Die Ausgangsfrage wirkte binär: SaaS-Prämien weiterzahlen oder etwas Günstigeres bauen. Die Einzelposten erzählten eine andere Geschichte.

Auf dem Papier gewann die Eigenentwicklung um $175K. Die Empfehlung lautete anders.

Warum die „günstigere" Eigenentwicklung für den Kunden falsch war: Es gab kein Senior-Engineering-Team, das dauerhaft 0,5 FTE Wartungsaufwand übernehmen konnte. Die Engineering-Organisation lieferte bereits das Kernprodukt aus. 10–15 % der Senior-Kapazität dauerhaft für Revenue-Ops-Wartung zu binden hätte entweder die Produkt-Roadmap verlangsamt oder neue Einstellungen erfordert — was die echte Entwicklungs-TCO bei Marktpreisen (nicht bei absorbierter Kapazität) auf über $800K getrieben hätte. Die „günstige" Zahl setzte kostenlose Ingenieure voraus. Ingenieure sind nie kostenlos.

Was wir tatsächlich umgesetzt haben: eine Kombination. Salesforce bleibt als System of Record. Eine dünne individuelle Revenue-Ops-Schicht ($85K Aufwand, nahezu keine laufenden Kosten) wurde für die 4 Workflows entwickelt, die Salesforce nicht sauber abbilden konnte. Die 5-Jahres-TCO landete bei ~$420K — zwischen den beiden Ausgangszahlen — und der Kunde bekam die Workflows, die er tatsächlich brauchte. Fertiggestellt in 11 Wochen, keine neuen Einstellungen, kein Roadmap-Verzug.

18 Monate später: Die individuelle Schicht ist noch in Produktion, Salesforce-Erneuerungen liefen problemlos durch und das Engineering-Team musste nach dem initialen Build nicht in die RevOps-Wartung zurückwechseln. Fazit: Die Kombination war die richtige Antwort, weil sie die Engineering-Kapazitätsbeschränkung berücksichtigte, die die reine Entwicklungsrechnung ignoriert hatte.

Zahlen anonymisiert und gerundet gemäß Beratungsvertrag. Kosten setzen einen Zeitraum 2025–2030 voraus. Salesforce-Preise spiegeln Listenpreiserhöhungen nach August 2025 wider. Produktivitätsgewinne durch KI-Coding-Agenten (Baseline Q3 2025) sind bereits in den $312K-Engineering-Schätzungen eingerechnet. Engineering vollständig kalkuliert mit $230K = US-Küsten-Median laut BLS 2024 + 30 % Sozialleistungen + 25 % Gemeinkosten, ±30 % je nach Standort anpassen. Wir sind eine Engineering-Agentur. Dies war eine echte Empfehlung gegen unser eigenes Geschäftsinteresse.

Wie KI die Software-Beschaffungsrechnung 2026 verändert hat

Der Umkehrpunkt hat sich verschoben. KI-Coding-Agenten haben den Senior-Engineering-Aufwand pro Feature in unseren internen Messungen über Kundenprojekte 2026 um 40–60 % reduziert. Eine Entwicklungsschätzung von 2023 ist heute materiell falsch. Gartner prognostiziert, dass 75 % der Enterprise-Software-Ingenieure bis 2028 KI-Code-Assistenten nutzen werden — gegenüber 10 % im Jahr 2023 — und unsere Pipeline-Daten zeigen, dass der Großteil dieser Adoption bereits früher eingetreten ist.

Drei konkrete Verschiebungen:

• 18-monatige Individualentwicklungen werden jetzt in 6–8 Monaten fertig, wenn der Scope konstant gehalten wird. Die obige Kombinations-Fallstudie wurde in 11 Wochen fertiggestellt; der gleiche Scope hätte 2023 noch 18–20 Wochen gekostet.
• Die Teamgröße für interne Tools ist gesunken. Wir arbeiten routinemäßig mit 2-Ingenieur-Teams für Builds, die vor zwei Jahren 5 Ingenieure erforderten, weil KI-Coding-Agenten wie Cursor und Claude Code den Boilerplate-Aufwand übernehmen, der früher mittlere Kapazitäten gebunden hat.
• Der $312K-Entwicklungsvoranschlag des Fallstudien-Kunden lag rund 30 % unter dem, was dieselbe Schätzung 2023 ergeben hätte — bevor KI-natives Enterprise-Software-Engineering zum Standardarbeitsmodus wurde.

Ehrlicher Gegenpunkt: KI senkt die Entwicklungskosten, aber sie senkt auch die Kosten, die SaaS-Anbieter für neue Features zahlen. Der Preisdruck auf Anbieter ist real, einige SaaS-Preise werden sinken, und die Verschiebung des Umkehrpunkts geht nicht nur in eine Richtung. Der Richtungseffekt begünstigt trotzdem die Eigenentwicklung (vor allem Kombinationslösungen), weil die interne Engineering-Produktivität mit KI schneller wächst als der Anbieterpreisdruck.

Typische Entscheidungsfallen (Scheinkostenvorteile, Sunk Cost, NIH-Syndrom, Anbieter-Optimismus)

Vier Fallen, die wir immer wieder bei Beschaffungsentscheidungen beobachten:

1. Scheinkostenvorteil. Die günstigere Jahr-1-Zahl wählen und die 5-Jahres-TCO ignorieren. Die obige Fallstudie wäre beinahe so gelaufen. Der Listenpreis im ersten Jahr ist auf jedem Weg der kleinste Teil der Rechnung.
2. Sunk-Cost-Falle. Auf einer SaaS-Lösung bleiben, die man längst überholt hat, weil die Migration teuer erscheint. Die Migration ist meistens günstiger als weitere drei Jahre mit dem falschen Werkzeug. Rechnen Sie es durch.
3. NIH-Syndrom (Not Invented Here). Dinge selbst entwickeln, die besser gekauft werden sollten, weil das Engineering-Team das Problem interessant findet. Ein CRM ist nicht interessant. Ein Zahlungsdienstleister ist nicht interessant. Kaufen Sie beides.
4. Anbieter-Optimismus. Glauben, dass jede Demo-Zeile in Ihrer Umgebung ohne Integrationsaufwand funktioniert. Die Demo zeigt den besten Fall. Ihr Fall ist schwieriger. Rechnen Sie mit einem Abschlag von 30 % auf die Demo, bevor Sie vergleichen.

Der teuerste Fehler, den wir sehen: die günstigere Jahr-1-Zahl wählen und die 5-Jahres-Ausstiegskosten ignorieren.

Wie Techsy mit Software-Beschaffungsentscheidungen umgeht

Techsy entwickelt individuelle Enterprise-Plattformen, integriert SaaS in bestehende Stacks und übernimmt technische Due-Diligence-Analysen bei COTS-Evaluierungen für B2B-Kunden. Die Arbeit verteilt sich ungefähr 40/30/30 auf diese drei Bereiche.

Eine Techsy-Beschaffungsanalyse läuft so ab: ein einstündiges Discovery-Gespräch zur Scope-Erfassung, dann führen wir die 12-Punkte-Matrix live mit Ihnen in einer gemeinsamen Tabellenkalkulation durch, liefern ein TCO-Modell innerhalb einer Woche und senden eine schriftliche Empfehlung — die durchaus lauten kann: "SaaS kaufen, nicht uns beauftragen." Unsere letzten 3 Analysen: 1 Empfehlung Entwickeln, 1 Empfehlung Kaufen, 1 Empfehlung Kombinieren. Wir haben keine Quote. Wenn Sie über den größeren Kontext einer umfassenden KI-Transformation im Unternehmen nachdenken, ist die Beschaffungsanalyse meistens der richtige Ausgangspunkt. Vereinbaren Sie ein kostenloses 30-minütiges Beratungsgespräch.

Häufig gestellte Fragen

Was ist der Unterschied zwischen kaufen, entwickeln und auslagern in der Softwarebeschaffung?

Kaufen bedeutet, bestehende SaaS- oder COTS-Software zu lizenzieren. Entwickeln bedeutet, individuelle Software mit eigenen Ingenieuren zu bauen. Auslagern bedeutet, eine Agentur oder einen Auftragnehmer mit der Entwicklung proprietärer Software zu beauftragen, die Sie besitzen. Gartner fasst dies unter Buy/Build/Blend zusammen, wobei Blend lizenzierte COTS für Standardworkflows mit individuellem Code für differenzierte Workflows kombiniert — ein Modell, das heute 76 % der Enterprise-Software-Ausgaben abdeckt.

Wann sollte man Software selbst entwickeln statt zu kaufen?

Entwickeln ist richtig, wenn drei Bedingungen zutreffen: Die Fähigkeit ist ein Wettbewerbsvorteil, für den Kunden Sie wählen; Sie haben ein Senior-Engineering-Team, das die Lösung 5+ Jahre betreiben kann, ohne Ihre Roadmap zu verlangsamen; und die 5-Jahres-SaaS-TCO übersteigt bei Ihrer Nutzerzahl die Entwicklungs-TCO um mindestens das Doppelte. Fehlt eine dieser drei Bedingungen, gewinnt Kombinieren oder Kaufen bei ehrlicher Rechnung fast immer.

Wann ist SaaS kaufen günstiger als individuelle Softwareentwicklung über 5 Jahre?

Kaufen gewinnt bei der TCO, wenn Sie weniger als ~100 Nutzer auf dem Workflow haben, die Fähigkeit standardisiert ist (CRM, E-Mail, Buchhaltung, Observability) und Sie sie in unter 90 Tagen live benötigen. Unterhalb dieser Schwellen ist das SaaS-Abonnement selbst mit jährlichen Preiserhöhungen günstiger als vollständig kalkuliertes Engineering plus Wartung plus Infrastruktur plus Opportunitätskosten.

Was sagt Gartner zum Thema kaufen oder entwickeln?

Gartner lehnt die binäre Fragestellung ab und nutzt ein dreigliedriges Buy/Build/Blend-Modell. Die Daten zeigen, dass 76 % der Enterprise-Software-Ausgaben heute in kombinierte Stacks fließen (lizenzierte COTS plus individuelle Erweiterungen), nicht in reine Einzellösungen. Gartner berichtet außerdem, dass Unternehmen 50–70 % der echten TCO in ersten Berechnungen übersehen — hauptsächlich bei Integration, Verwaltungs-FTE-Zuweisung und Ausstiegskosten.

Ist die Kaufen-oder-Entwickeln-Entscheidung überholt?

Die binäre Formulierung ist überholt. Die dreigliedrige Entscheidung nicht. Die Frage "kaufen oder entwickeln" verschleiert, dass die meisten Unternehmen am Ende kombinieren: SaaS für Standardworkflows, Individualentwicklung für die differenzierten — und Verbindungstechnologie dazwischen. Die Entscheidung ist lebendig und komplexer als sie aussieht, weil Sie jetzt den Trennpunkt festlegen müssen, nicht eine Seite wählen. Formulieren Sie sie als Buy/Build/Blend, und die Rechnung wird klarer.

Wie verändern KI-Coding-Tools (Cursor, Claude Code) die Software-Beschaffungsrechnung 2026?

KI-Coding-Agenten wie Cursor und Claude Code reduzieren den Senior-Engineering-Aufwand pro Feature um 40–60 % in unseren 2026-Messungen über Kundenprojekte. Das verschiebt den Umkehrpunkt: Entwicklungsprojekte, die 2023 nicht rentabel waren, sind es jetzt. Gartner prognostiziert, dass 75 % der Enterprise-Software-Ingenieure bis 2028 KI-Code-Assistenten nutzen werden — diese Verschiebung ist dauerhaft, nicht temporär. 18-Monats-Builds werden routinemäßig in 6–8 Monaten fertig.

Wie hoch sind die typischen jährlichen Wartungskosten für individuelle Enterprise-Software?

Die Faustformel der Branche lautet: 15–20 % der ursprünglichen Entwicklungskosten pro Jahr, dauerhaft. Eine individuelle Plattform für $300K sollte jährlich $45K–$60K für Wartung einplanen (Fehlerbehebungen, Dependency-Updates, Sicherheits-Patches, kleinere Verbesserungen). Das schließt größere neue Features aus, die als separates Entwicklungsprojekt behandelt werden. Zu niedrig angesetzte Wartungskosten sind der häufigste Fehler in individuellen Entwicklungs-TCO-Modellen.

Was sind die versteckten Kosten beim Kauf von Enterprise-SaaS?

Die sechs Kostenposten, die die meisten Demos überspringen: Anbieterabhängigkeit (6–18 Monate für einen Wechsel), Anpassungs- und Änderungsgebühren ($200–500/Std.), Lizenzmengen-Creep bei 7–15 % jährlich mit Organisationswachstum, Integrationskosten ($20K–$100K je verbundenem System), Ausstiegs- und Migrationskosten (3–6 Engineering-Monate) und jährliche Preiserhöhungen von 7–15 % unabhängig von der Nutzung. Die Jahr-1-Lizenzgebühr macht selten mehr als 30–40 % der echten 5-Jahres-Kosten aus.

Was bedeutet Total Cost of Ownership (TCO) bei Software?

TCO sind die vollständigen 5-Jahres-Kosten eines Software-Wegs: Lizenzgebühren oder Entwicklungsaufwand, Implementierung, Schulungen, Integration, laufende Wartung, Verwaltungs-FTE-Zuweisung, Opportunitätskosten und Ausstiegs-/Migrationskosten beim späteren Wechsel. Gartner-Forschung zeigt, dass Unternehmen in ersten Berechnungen typischerweise 50–70 % der echten TCO übersehen. Rechnen Sie es durch, bevor Sie sich festlegen, nicht danach.

Wie groß muss ein Unternehmen sein, um individuelle Enterprise-Software zu rechtfertigen?

Grobe Faustregel: ~$10M+ ARR oder ~50+ Nutzer auf dem jeweiligen Workflow. Unterhalb dieser Schwelle gewinnt fast immer das SaaS-Abonnement, weil Engineering und Wartung nicht auf ausreichend Nutzung umgelegt werden können. Darüber beginnt die Rechnung Eigenentwicklung oder Kombinationslösungen zu begünstigen — besonders wenn der Workflow zentral für Ihre Wettbewerbsposition ist. KI-Coding-Agenten senken diese Schwelle 2026 gegenüber der 2023-Baseline um 20–30 %.

Fazit

Wenn Sie eine Erkenntnis aus diesem Beitrag mitnehmen: Prüfen Sie die Interessenlage jedes Frameworks, das Sie lesen, bevor Sie der Empfehlung vertrauen. Anbieter geben Anbieter-Ratschläge. Agenturen geben Agenturen-Ratschläge. Ihr CFO gibt CFO-Ratschläge. Lesen Sie drei davon, finden Sie die Überschneidungen und vertrauen Sie diesen.

• Führen Sie die 12-Punkte-Matrix live in einem Meeting durch. Sie kürzt die Diskussion von zwei Stunden auf zwanzig Minuten.
• Berechnen Sie die 5-Jahres-TCO ehrlich. Der Jahr-1-Listenpreis ist nie die Antwort.
• Wählen Sie standardmäßig Kombinieren, wenn Ihr Score zwischen 30 und 45 liegt. Die meisten Unternehmen landen ohnehin dort.

Wenn Sie einen zweiten Blick auf die Entscheidung haben möchten, vereinbaren Sie ein kostenloses 30-minütiges Beratungsgespräch. Wir empfehlen SaaS-Kauf, wenn das die richtige Antwort ist. Das ist schon passiert. Es wird wieder passieren.