Selbst bauen oder fertig kaufen? Vor dieser Frage steht früher oder später jedes Unternehmen, das Software braucht. Die Make-or-Buy-Entscheidung ist der strukturierte Weg zu einer Antwort: ein Abwägungsprozess, der klärt, ob eine Leistung im eigenen Haus erbracht (Make) oder am Markt eingekauft wird (Buy). Der Begriff stammt aus der klassischen Betriebswirtschaftslehre und hat sich längst vom Fabrikhof in die IT verlagert. Dort entscheidet er heute über Budgets, Teamgrößen und nicht selten über die Wettbewerbsfähigkeit ganzer Geschäftsmodelle.
Im Software-Kontext lautet die Frage konkret: Individualsoftware entwickeln lassen oder Standardsoftware beziehungsweise SaaS einführen? Beide Wege funktionieren. Beide können teuer schiefgehen. Welcher passt, hängt nicht vom Bauchgefühl ab, sondern von einer Handvoll Kriterien, die sich sauber prüfen lassen.
Woher der Begriff kommt
In der Betriebswirtschaftslehre heißt das Thema Eigenfertigung oder Fremdbezug und gehört zu den Grundfragen von Beschaffung und Produktion. Ein Automobilhersteller entscheidet, ob er Sitze selbst fertigt oder von einem Zulieferer bezieht. Ein Maschinenbauer entscheidet, ob er die Steuerungssoftware im Haus entwickelt oder einkauft. Die Summe solcher Entscheidungen bestimmt die Fertigungstiefe eines Unternehmens und damit einen guten Teil seiner Kostenstruktur.
Theoretisch untermauert wurde die Frage schon 1937: Der Ökonom Ronald Coase argumentierte in „The Nature of the Firm", dass Unternehmen genau dort selbst produzieren, wo die Transaktionskosten des Einkaufens am Markt höher wären als die Kosten der internen Koordination. Oliver Williamson baute daraus später die Transaktionskostentheorie, für die er 2009 den Wirtschaftsnobelpreis erhielt. Übersetzt in den Alltag: Kaufen ist nicht automatisch billiger. Suchen, Verhandeln, Anpassen und Kontrollieren kosten ebenfalls Geld, nur taucht es in keinem Angebot auf.
Make or Buy im Software-Kontext
In der IT verschiebt sich die Bedeutung leicht. „Make" heißt Eigenentwicklung: Software, die exakt auf die eigenen Prozesse zugeschnitten ist. Wichtig dabei: Make bedeutet nicht zwingend ein eigenes Entwicklerteam. Auch wer eine Agentur oder ein Softwarehaus mit der Entwicklung beauftragt, trifft eine Make-Entscheidung, solange ihm am Ende der Code gehört und er die Weiterentwicklung steuert.
„Buy" heißt Standardsoftware oder SaaS: ein fertiges Produkt, das viele Unternehmen mit ähnlichen Anforderungen nutzen, vom ERP über das CRM bis zum Shopsystem. Auch hier lohnt eine Klarstellung. Buy bedeutet nicht „keine Arbeit". Einführung, Konfiguration, Datenmigration und Schnittstellenbau kosten Zeit und Geld, in manchen Projekten mehr als die Lizenz selbst.
Die fünf Kriterien, die wirklich zählen
Klassische Make-or-Buy-Analysen vergleichen vor allem Kosten. Für Software greift das zu kurz, weil die teuersten Fehler selten im Anschaffungspreis stecken, sondern in Abhängigkeiten, die erst Jahre später sichtbar werden. Fünf Kriterien haben sich als tragfähig erwiesen:
| Kriterium | Leitfrage | Typische Tendenz |
|---|---|---|
| Differenzierung | Verschafft dir dieser Prozess einen Vorsprung im Wettbewerb? | Ja → Make, Nein → Buy |
| Integrationsfläche | Wie viele Systeme mit wie vielen Sonderfällen müssen angebunden werden? | Viele Sonderfälle → Make wird attraktiver |
| Exit-Pfad | Kommst du mit Daten und Prozessen wieder heraus? | Kein sauberer Export → Buy wird riskant |
| Wartung & TCO | Was kostet die Lösung über fünf Jahre, inklusive Betrieb und Pflege? | Ergebnisoffen, ehrlich rechnen |
| Ownership | Wer kontrolliert Code, Daten und Roadmap? | Kontrolle nötig → Make |
Differenzierung ist das wichtigste Kriterium und zugleich das am häufigsten missverstandene. Die Faustregel: Kauf das Commodity, bau den Vorsprung. Buchhaltung, Lohnabrechnung, E-Mail und Videokonferenzen unterscheiden dich von keinem Wettbewerber, also wäre Eigenentwicklung hier verbranntes Geld. Der Prozess dagegen, mit dem du schneller lieferst, besser berätst oder präziser kalkulierst als der Rest des Marktes, ist dein Geschäft. Ihn einer Standardsoftware anzuvertrauen heißt, ihn auf das Niveau aller anderen Nutzer derselben Software zu nivellieren.
Integrationsfläche beschreibt, wie tief die neue Lösung in deine Systemlandschaft eingreifen muss. Standardsoftware lebt von Standardprozessen. Je mehr Altsysteme, Sonderfälle und gewachsene Datenstrukturen angebunden werden müssen, desto mehr Customizing braucht das gekaufte Produkt, und Customizing ist genau der Punkt, an dem Buy-Projekte ihre Kostenvorteile verlieren. Ab einer gewissen Zahl an Ausnahmen ist die ehrliche Antwort oft: Eine schlanke Eigenentwicklung um die vorhandenen Systeme herum ist billiger als ein totgebogenes Standardprodukt.
Exit-Pfad heißt: Du planst den Ausstieg, bevor du einsteigst. Bekommst du deine Daten in einem offenen Format wieder heraus? Gibt es dokumentierte APIs? Was passiert bei einer Preiserhöhung, einer Übernahme des Anbieters oder einer Produktabkündigung? Wer diese Fragen erst stellt, wenn der Vertrag läuft, hat sie faktisch schon verloren. Das Risiko dahinter hat einen Namen: Vendor Lock-in.
Wartung und Gesamtkosten entscheiden sich nicht am Kaufpreis, sondern an der Total Cost of Ownership (TCO) über einen realistischen Zeitraum, üblicherweise drei bis fünf Jahre. Bei Make trägst du Betrieb, Security-Patches, Weiterentwicklung und das Risiko, dass Wissen mit Personen das Haus verlässt. Bei Buy zahlst du Subscriptions, die mit Nutzern oder Umsatz mitwachsen, plus Customizing und Upgrades. Beide Rechnungen sehen im ersten Jahr anders aus als im fünften. Genau deshalb muss man beide über denselben Zeitraum aufmachen.
Ownership schließlich ist die Frage nach der Kontrolle über die Roadmap. Bei Eigenentwicklung priorisierst du, was gebaut wird. Bei Standardsoftware entscheidet der Hersteller, und zwar für alle Kunden gleichzeitig. Wie real dieses Risiko ist, zeigt ein aktuelles Beispiel: Shopify stellt seine Scripts-Funktion zum 30. Juni 2026 endgültig ein. Händler, die ihre Rabatt- und Checkout-Logik darauf aufgebaut haben, müssen auf Shopify Functions migrieren, ob es in ihre Planung passt oder nicht. Das ist kein Vorwurf an Shopify, sondern die Natur von Buy: Die Roadmap gehört dem Anbieter.
Ein Durchlauf am Beispiel: PIM kaufen oder bauen?
Wie die Kriterien zusammenspielen, zeigt ein typischer Fall aus dem E-Commerce: Ein Händler mit 80.000 Artikeln braucht ein Product-Information-Management-System. Auf dem Markt gibt es etablierte Produkte wie Akeneo oder Pimcore, beide mit Open-Source-Kern. Die Alternative wäre eine Eigenentwicklung.
Der Kriterien-Durchlauf fällt hier ziemlich eindeutig aus. Produktdaten zu pflegen ist für die meisten Händler keine Differenzierung, sondern Pflicht. Die Integrationsfläche ist überschaubar, weil PIM-Systeme genau für den Datenfluss zwischen ERP, Shop und Marktplätzen gebaut sind. Der Exit-Pfad ist bei Open-Source-Produkten strukturell besser als bei proprietärem SaaS, weil Datenmodell und Code offenliegen. Und die TCO einer Eigenentwicklung, die mit ausgereiften Produkten konkurrieren müsste, wäre kaum zu rechtfertigen. Ergebnis: Buy, mit gezieltem Customizing an den Rändern. Anders läge der Fall nur, wenn die Produktdatenlogik selbst das Geschäftsmodell wäre, etwa bei einem Anbieter konfigurierbarer Sonderanfertigungen, dessen Regelwerk kein Standard-PIM abbildet.
Typische Fehler bei Make-or-Buy-Entscheidungen
Die meisten Fehlentscheidungen folgen wiederkehrenden Mustern:
- Nur den Anschaffungspreis vergleichen. Lizenz gegen Entwicklungsbudget zu stellen ignoriert Betrieb, Wartung, Customizing und Exit-Kosten, also den Großteil der Rechnung.
- Buy kaufen und dann totcustomizen. Wer Standardsoftware so lange verbiegt, bis sie die eigenen Sonderprozesse abbildet, zahlt doppelt: die Lizenz und eine faktische Eigenentwicklung obendrauf, die bei jedem Hersteller-Update bricht.
- Die eigene Einzigartigkeit überschätzen. Fast jedes Unternehmen hält seine Prozesse für besonders. Die harte Gegenfrage lautet: Würde ein Kunde für diesen Unterschied mehr bezahlen? Wenn nein, ist es keine Differenzierung.
- Make unterschätzen. Eigenentwicklung endet nicht mit dem Go-live. Betrieb, Sicherheitsupdates, Dokumentation und die Abhängigkeit von einzelnen Wissensträgern gehören von Anfang an in die Kalkulation.
- Den Exit-Pfad ignorieren. Solange alles läuft, wirkt die Frage akademisch. Sie wird konkret, wenn die Preisliste sich ändert oder ein Feature abgekündigt wird, und dann ist es zu spät für gute Verhandlungspositionen.
- Die Entscheidung als endgültig behandeln. Märkte, Anbieter und die eigene Firma ändern sich. Eine Make-or-Buy-Entscheidung von 2020 verdient 2026 eine Überprüfung, keine Verteidigung.
Der dritte Weg: Hybrid statt Entweder-oder
In der Praxis sind die wenigsten guten Architekturen reines Make oder reines Buy. Der belastbarste Ansatz kombiniert beides: ein bewährtes Standardprodukt als Fundament, Eigenentwicklung dort, wo das Geschäft besonders ist. Ein Shopsystem wie Shopware wird gekauft, die branchenspezifische Preislogik, der Produktkonfigurator oder die ERP-Anbindung werden als eigene Erweiterungen entwickelt. Das Standardprodukt liefert Sicherheit, Updates und ein Ökosystem; die Erweiterungen liefern den Vorsprung.
Auch Open Source ist im Kern ein hybrider Weg: Du kaufst nichts, entwickelst aber auch nicht bei null, sondern übernimmst eine offene Codebasis und trägst dafür Betrieb und Anpassung selbst. Und zwischen den Systemen wächst eine dritte Kategorie, die eigene Integrationsschicht: Wer mehrere Buy-Produkte einsetzt, entwickelt die Middleware, die sie verbindet, zunehmend selbst, etwa mit Workflow-Werkzeugen wie n8n. Die Make-or-Buy-Frage verschwindet dadurch nicht. Sie wird nur kleinteiliger und ehrlicher: nicht „bauen wir alles selbst?", sondern „welche Bausteine gehören uns, und welche mieten wir?".
Häufige Fragen zur Make-or-Buy-Entscheidung
Ist beauftragte Individualentwicklung Make oder Buy?
Make. Entscheidend ist nicht, wer tippt, sondern wem das Ergebnis gehört. Wenn du den Quellcode besitzt, die Roadmap bestimmst und den Dienstleister wechseln könntest, ist es eine Make-Entscheidung mit eingekaufter Umsetzungskapazität. Buy liegt erst vor, wenn du ein fertiges Produkt nutzt, dessen Code und Roadmap beim Hersteller bleiben.
Wann ist Standardsoftware die falsche Wahl?
Wenn der Prozess, den sie abbilden soll, dein Differenzierungsmerkmal ist, oder wenn der Customizing-Aufwand die Kosten einer schlanken Eigenentwicklung erreicht. Ein verlässliches Warnsignal: Das Projektteam spricht mehr über Workarounds um die Software herum als über die Software selbst.
Wie rechnet man Make gegen Buy seriös?
Über die Total Cost of Ownership beider Varianten für denselben Zeitraum, meist drei bis fünf Jahre. Auf der Make-Seite gehören Entwicklung, Betrieb, Wartung und Personalrisiko hinein, auf der Buy-Seite Lizenzen beziehungsweise Subscriptions, Einführung, Customizing, Upgrades und die geschätzten Exit-Kosten. Erst wenn beide Rechnungen vollständig sind, ist der Vergleich fair.
Gibt es einen Mittelweg zwischen Make und Buy?
Ja, und er ist in der Praxis der Normalfall: Standardsoftware als Basis, Eigenentwicklung für die geschäftskritischen Besonderheiten, dazu Open Source und selbst entwickelte Integrationsschichten. Die Frage stellt sich dann nicht einmal pro Unternehmen, sondern pro Baustein der Architektur.
Wie oft sollte man eine Make-or-Buy-Entscheidung überprüfen?
Bei jedem größeren Auslöser: Preismodell-Änderung oder Abkündigung beim Anbieter, deutliches Wachstum, neue regulatorische Anforderungen oder ein Strategiewechsel im eigenen Haus. Als Daumenregel lohnt ein kurzer Review alle zwei bis drei Jahre, auch ohne akuten Anlass.