Die meisten Unternehmen bauen zu viel selbst. Nicht, weil es wirtschaftlich sinnvoll wäre, sondern weil Eigenentwicklung sich nach Kontrolle anfühlt. Nach Strategie. Nach "wir haben das im Griff".
Die Realität: Laut dem Standish Group CHAOS Report scheitern 69% aller IT-Projekte teilweise oder vollständig. Gleichzeitig verschlingt die Wartung bestehender Eigenentwicklungen im Schnitt 80% des IT-Budgets. Für neue Features, Innovation oder tatsächliche Wertschöpfung bleiben 20%.
Die Make or Buy Entscheidung bei Software hat sich verschoben. Wer heute noch reflexartig "bauen" sagt, verbrennt Geld und Zeit.
Was bedeutet Make or Buy bei Software?
Die Make or Buy Entscheidung beschreibt die strategische Wahl zwischen Eigenentwicklung ("Make") und dem Einkauf einer fertigen Lösung ("Buy") -- ob als SaaS-Plattform, Lizenzprodukt oder managed Service.
Bei Software geht es dabei nicht um Beschaffung im klassischen Sinne. Es geht um die Frage: Ist diese Fähigkeit so zentral für unser Geschäftsmodell, dass wir sie kontrollieren müssen? Oder ist sie Infrastruktur, die andere besser und günstiger liefern?
Die Antwort fällt in der Praxis oft anders aus, als die meisten Teams erwarten.
Wann lohnt sich Eigenentwicklung?
Selbst bauen rechnet sich in genau einem Szenario: Wenn die Software direkt zur Differenzierung beiträgt und einen echten Daten- oder Prozessvorteil schafft, den kein Standardprodukt abbilden kann.
- Die Software verarbeitet proprietäre Daten, die das Unternehmen über Jahre aufgebaut hat. Diese Daten sind der eigentliche Moat.
- Der Workflow ist so spezifisch, dass kein Produkt auf dem Markt ihn abbildet. "Spezifisch" heißt hier: wirklich einzigartig, nicht "wir machen es halt anders".
- Die Abhängigkeit von einem Anbieter wäre existenzbedrohend, etwa bei regulierten Branchen, in denen die Daten das Haus nicht verlassen dürfen.
Ein Beispiel: Quantitative Hedgefonds bauen ihre Trading-Systeme selbst. Die Algorithmen, die Daten-Pipelines, die Execution Engine -- das ist ihr Produkt. Wer das einkauft, hat keinen Vorteil mehr.
Aber die allermeisten Unternehmen sind keine Hedgefonds. Und das CRM, das Analyse-Tool oder die Due-Diligence-Plattform sind keine Differenzierungsmerkmale. Sie sind Werkzeuge.
Wann ist Kaufen die bessere Entscheidung?
In den meisten Fällen. Ernsthaft.
Kaufen schlägt Bauen, wenn mindestens zwei der folgenden Punkte zutreffen:
- Die Funktion ist nicht direkt umsatzrelevant oder wettbewerbsdifferenzierend
- Es existieren etablierte Produkte mit aktivem Ökosystem und regelmässigen Updates
- Time-to-Value zählt: Das Team braucht die Lösung in Wochen, nicht Monaten
- Die interne Entwicklungskapazität ist begrenzt und wird für Kernproduktarbeit gebraucht
- Die Wartung einer Eigenentwicklung würde langfristig Ressourcen binden
Die Zahlen sind eindeutig: Laut einer Analyse der Standish Group werden nur 31% aller IT-Projekte termingerecht, im Budget und mit vollem Scope abgeschlossen. Bei grossen Projekten (das typische "wir bauen das selbst"-Kaliber) liegt die Erfolgsquote unter 10%.
Dazu kommt der versteckte Kostenfaktor: McKinsey beziffert den Anteil von Technical Debt am IT-Budget auf 10-20% bei neuen Produkten. Tendenz steigend. 60% der befragten CIOs berichten, dass ihr Technical Debt in den letzten drei Jahren spürbar gewachsen ist.
Die tatsächlichen Kosten: TCO-Vergleich Make vs. Buy
Der häufigste Denkfehler bei der Make or Buy Entscheidung: Teams vergleichen Entwicklungskosten mit Lizenzkosten. Das ist, als würde man den Kaufpreis eines Autos mit der monatlichen Leasingrate vergleichen, ohne Versicherung, Wartung und Wertverlust einzurechnen.
Gartner schätzt, dass Unternehmen 50-70% der Gesamtkosten übersehen, wenn sie Software-Ownership kalkulieren.
| Kostenfaktor | Eigenentwicklung (5 Jahre) | SaaS / Buy (5 Jahre) |
|---|---|---|
| Initiale Entwicklung / Setup | 30-35% des TCO | 10-15% des TCO |
| Personal (Wartung, Updates) | 50-85% des TCO | 0% (beim Anbieter) |
| Infrastruktur | 10-15% | ca. 5% |
| Upgrades und Weiterentwicklung | 15-25% | Im Abo enthalten |
| Gesamtstruktur | Front-loaded + laufend hoch | Vorhersehbar, linear |
Ein Rechenbeispiel: Bei einem initialen Entwicklungsbudget von 500.000 Euro fallen über fünf Jahre Personalkosten für Wartung und Weiterentwicklung von 1,25 bis 2,1 Millionen Euro an. Die Gesamtkosten liegen bei 1,75 bis 2,6 Millionen Euro. Für ein einziges internes Tool.
Dem gegenüber steht ein SaaS-Abo, das typischerweise in 4-6 Wochen produktiv ist, statt in 36-54 Wochen Entwicklungszeit.
Wie hat KI die Make or Buy Entscheidung verändert?
Radikal. Und zwar in beide Richtungen.
Was KI auf der "Buy"-Seite verändert hat: Fertige Produkte sind massiv leistungsfähiger geworden. Was vor drei Jahren noch eine Eigenentwicklung mit eigenem ML-Team erforderte, gibt es heute off the shelf: Datenextraktion aus unstrukturierten Quellen, automatisierte Analysen, natürlichsprachige Abfragen. LLMs haben die Fähigkeiten von Standardsoftware um Grössenordnungen erweitert.
Was KI auf der "Make"-Seite verändert hat: Entwicklungszeiten sind durch AI-gestütztes Coding kürzer geworden. Prototypen entstehen schneller. Aber die Wartung bleibt. AI-generierter Code erzeugt genauso Technical Debt wie menschlich geschriebener. Eher mehr, weil weniger Entwickler*innen den Code im Detail verstehen.
Die eigentliche Verschiebung: Der Differenzierungsvorteil durch Eigenentwicklung ist geschrumpft. Wenn ein SaaS-Tool mit KI-Agenten in Wochen liefert, was ein internes Team in Monaten baut, wird die "Make"-Entscheidung zum Wettbewerbsnachteil.
Was sich nicht verändert hat: Proprietary Data bleibt ein Moat. Aber der Moat entsteht durch die Daten selbst, nicht durch die Software, die sie verarbeitet.
Die 5 Entscheidungskriterien für Make or Buy
Statt Bauchgefühl: Fünf Kriterien, die eine klare Antwort liefern.
1. Differenzierung
Ist die Fähigkeit, die die Software liefert, ein direkter Wettbewerbsvorteil?
- Make, wenn: Die Software verarbeitet Daten oder Prozesse, die kein anderes Unternehmen hat
- Buy, wenn: Mehrere Anbieter die gleiche Funktion anbieten und Ihre Wettbewerber sie auch nutzen
2. Time-to-Value
Wie schnell braucht das Team die Lösung?
- Make, wenn: Die Timeline flexibel ist und der Wert erst langfristig entsteht
- Buy, wenn: In 4-8 Wochen ein funktionierendes System stehen muss
3. Total Cost of Ownership
Was kostet Entwicklung, Betrieb, Wartung und Weiterentwicklung über 3-5 Jahre?
- Make, wenn: Die interne Kapazität vorhanden ist und nicht von Kernprodukten abgezogen wird
- Buy, wenn: Die Gesamtkosten der Eigenentwicklung das Zwei- bis Dreifache eines SaaS-Abos betragen (was fast immer der Fall ist)
4. Wartung und Weiterentwicklung
Wer übernimmt Updates, Security Patches, Feature-Requests?
- Make, wenn: Ein dediziertes Team dauerhaft verfügbar ist und bleibt
- Buy, wenn: Die Wartung sonst an den teuersten Entwickler*innen im Team hängenbleibt
5. Daten-Moat
Entsteht durch die Nutzung der Software ein proprietary Datenvorteil?
- Make, wenn: Die Software selbst Daten generiert oder anreichert, die einen kumulativen Vorteil schaffen
- Buy, wenn: Die Software Daten verarbeitet, aber der Datenvorteil aus anderen Quellen stammt
| Kriterium | Tendenz "Make" | Tendenz "Buy" |
|---|---|---|
| Differenzierung | Einzigartiger Prozess / Daten | Standardfunktion |
| Time-to-Value | > 6 Monate akzeptabel | < 8 Wochen nötig |
| TCO (5 Jahre) | Internes Team vorhanden | Eigenentwicklung > 2x SaaS |
| Wartung | Dediziertes Team gesichert | Keine eigene Kapazität |
| Daten-Moat | Software erzeugt Moat | Daten kommen von aussen |
Die häufigsten Fehler bei der Make or Buy Entscheidung
"Wir bauen, weil es strategisch ist"
Der mit Abstand häufigste Fehler. Teams verwechseln "wir haben Kontrolle" mit "das ist strategisch relevant". Ein internes Research-Tool zu bauen ist nicht strategisch, wenn das gleiche Tool als Produkt existiert und das eigene Analysten-Team damit in zwei Wochen produktiv wäre statt in sechs Monaten.
Wartungskosten unterschätzen
Die Entwicklung ist der kleinere Teil. Die meisten Teams planen das Budget für den Launch, nicht für die folgenden fünf Jahre. Ergebnis: Das Tool funktioniert, aber niemand hat Zeit, es weiterzuentwickeln. Es wird zum digitalen Altbau.
Opportunitätskosten ignorieren
Jede Stunde, die eine Entwicklerin an einem internen Tool arbeitet, fehlt am Kernprodukt. Bei einem VC-Fonds, der ein eigenes Sourcing-System baut, statt eines zu kaufen, arbeiten die teuersten Köpfe an Infrastruktur statt an Deals. Ein VC-Audit zeigte: 34 fragmentierte Tools und 542 manuelle Aufgaben. Das Ergebnis von Jahren ad-hoc "Make"-Entscheidungen.
Nicht testen, bevor man baut
Viele Teams starten die Eigenentwicklung, ohne vorher drei bis vier Produkte ernsthaft getestet zu haben. Zwei Wochen mit einem SaaS-Tool im Trial zeigen oft, dass 80% der Anforderungen bereits abgedeckt sind. Die restlichen 20% rechtfertigen selten eine sechsstellige Eigenentwicklung.
Wann "Blend" die richtige Antwort ist
Gartner empfiehlt inzwischen ein drittes Modell: Buy, Build, and Blend. 76% der Enterprise-Software-Ausgaben fliessen laut Gartner bereits in Kombinationen aus Standardprodukten und Low-Code-Erweiterungen.
- Buy die Kernplattform (CRM, Analyse, Research, Due Diligence)
- Build die Integrationsschicht, die Ihre proprietären Datenquellen anbindet
- Blend beides über APIs und Automatisierung
Dieser Ansatz kombiniert die Geschwindigkeit und Wartungsfreiheit eines Standardprodukts mit der Flexibilität, eigene Daten und Workflows einzubinden. Für Teams, die mit alternativen Datenquellen arbeiten, ist das oft der pragmatischste Weg.
Von der Entscheidung zum Wettbewerbsvorteil
Die Make or Buy Entscheidung bei Software ist keine IT-Frage. Es ist eine Ressourcenentscheidung. Und die Antwort ist in 80% der Fälle: kaufen. Die freiwerdende Kapazität dort einsetzen, wo sie echten Wert schafft.
Die Unternehmen, die das früh verstanden haben, arbeiten mit KI-gestützten Plattformen, statt eigene zu bauen. Sie investieren ihre Engineering-Kapazität in proprietäre Daten und Prozesse, nicht in Infrastruktur, die ein SaaS-Anbieter besser wartet.
Die Frage ist nicht, ob Sie sich das Bauen leisten können. Die Frage ist, ob Sie sich das Nicht-Kaufen leisten können, während Ihre Wettbewerber in Wochen produktiv sind.
Researchly statt Eigenentwicklung: Der Research-Stack, der sofort liefert
VC-Teams, PE-Firmen und Beratungen stehen genau vor dieser Entscheidung: eigene Research-Infrastruktur bauen oder ein Tool nutzen, das den Stack bereits abdeckt.
Researchly liefert, was interne Teams in Monaten nicht schaffen:
- Automatisiertes Sourcing und Screening -- KI-Agenten, die aus hunderten Datenquellen relevante Targets identifizieren
- Due-Diligence-Reports in Minuten -- statt wochenlanger manueller Recherche, mit Quellenverweis für jede Aussage
- Portfolio-Monitoring in Echtzeit -- automatische Alerts bei relevanten Veränderungen, ohne eigene Daten-Pipeline bauen zu müssen
Statt sechs Monate an einem internen Tool zu bauen, testen Sie in 14 Tagen, ob der Stack passt.
