Custom Software · Vertiefung
Eigenentwicklung oder Plattform: das Build-vs-Buy-Entscheidungsraster
Wann eigene Software entwickeln und wann eine Plattform kaufen: ein Entscheidungsraster auf Basis von Prozess-Fit, Gesamtbetriebskosten, Lock-in, Datenhoheit und Time-to-Value.
ARCHITEKTUR · BUILD-VS-BUY
Rein · Benötigte Fähigkeiten
Raus · Build / Buy / Compose
Kern vs. Commodity (Value Map)
Zerlegt das System in seine Fähigkeiten und verortet jede auf der Core/Commodity-Achse: trennt, was Sie am Markt differenziert — und eigenen Code verdient — von dem, was zur Commodity geworden ist und schlicht beim günstigsten Anbieter gekauft wird.
Passung zum Prozess
Misst, wie proprietär Ihr Workflow ist: ein generischer Prozess mit gefestigten Branchenstandards drängt zur Plattform, während ein Workflow, der Teil Ihres Vorteils ist, zur Eigenentwicklung drängt — denn hier kosten die von einer Plattform erzwungenen Workarounds mehr als zweckgebauter Code.
TCO über 5 Jahre
Berechnet die Fünf-Jahres-Kosten inklusive Wartung, Integration und Schulung — nicht nur Lizenz oder Erstangebot —, denn der Großteil der Softwarekosten fällt nach dem Go-live an, und genau das kippt das Verdikt.
Lock-in & Exit-Rechte
Wägt die Ausstiegskosten ab, bevor Sie einsteigen: Verträge, Datenportabilität und fest verdrahtete Integrationen entscheiden, ob Sie bei der Verlängerung Spielraum haben oder ohne dastehen — vor einem Anbieter, der das weiß.
Datenhoheit
Prüft, dass die Daten, die Sie auszeichnen, Ihre bleiben — exportierbar in offenen Standards und unabhängig vom Anbieter: ein einziger nicht exportierbarer Posten kann die Entscheidung kippen, denn ein zur Geisel gewordenes Asset wiegt schwerer als jede Listenpreis-Ersparnis.
Time-to-Value
Wägt die Dringlichkeit des Werts gegen die Beständigkeit des Vorteils: eine bewährte, bereits verfügbare Lösung bringt Sie jetzt in Bewegung, während ein struktureller Differenzierer eine längere, getragene Umsetzung rechtfertigt.
Die Anzeichen, dass Ihre Build-vs-Buy-Linie an der falschen Stelle gezogen wurde
Die Frage lautet nie „Eigenentwicklung oder Plattform“. Sie lautet: Welche Fähigkeit verdient eigenen Code und welche ist eine Commodity zum Einkaufen. Diese Symptome bedeuten, dass die Linie an der falschen Stelle gezogen wurde.
- Sie passen eine Standardplattform an bis sie sich selbst nicht mehr ähnelt: Jedes Release des Anbieters bricht Ihre Konfiguration, und „von der Stange“ ist zu einem dauerhaften Entwicklungsprojekt geworden.
- Sie haben eine Commodity von Grund auf gebaut — Authentifizierung, Zahlungen, Benachrichtigungen — und Engineering-Kapazität auf Probleme verwendet, die der Markt längst gelöst hat, statt auf Ihren Wettbewerbsvorteil.
- Die Daten, die Sie auszeichnen, liegen bei einem Anbieter in einem proprietären Format ohne Export in offene Standards: Sie sind kein Asset mehr, sondern eine Geisel.
- Niemand hat je die Fünf-Jahres-Zahl berechnet : Die Entscheidung fiel auf Basis eines Lizenzpreises oder eines Entwicklungsangebots und ignorierte Wartung, Integration und Schulung, die den Lebenszyklus dominieren.
- Ein Anbieterwechsel ist undenkbar : Mehrjahresverträge, nicht portierbare Daten und fest verdrahtete Integrationen haben die Ausstiegskosten auf ein Niveau gehoben, das Ihnen bei der Verlängerung jeden Verhandlungsspielraum nimmt.
Für CTOs, COOs und operative Führungskräfte, die entscheiden müssen, wo sie Engineering-Kapazität investieren und wo sie sich auf den Markt stützen — mit Kriterien, die vor dem Vorstand standhalten.
Kaufe die Commodity, baue, was dich auszeichnet
Die belastbarste Betriebsregel ist nicht finanziell, sondern strategisch: jede Fähigkeit auf der Wertkarte verorten und danach entscheiden, wo sie sitzt, nicht nach den Vorlieben dessen, der den Code schreibt. Eine durch Wardley Mapping formalisierte Disziplin.
Core vs Commodity, nicht persönlicher Geschmack
Eine Fähigkeit, die Sie am Markt differenziert und sich schnell weiterentwickelt, verdient eigenen Code. Eine Fähigkeit, die zur Commodity geworden ist — dieselbe für Sie und Ihre Wettbewerber — ist eine Kostenstelle: Sie kaufen beim günstigsten Anbieter und gehen weiter. Eine Commodity zu bauen heißt, Engineering-Kapazität an einem gelösten Problem zu verbrennen.
Der Prozess-Fit ist die eigentliche Trennlinie
Ist Ihr Workflow generisch und hat die Branche gefestigte Standards, gewinnt eine Plattform durch Geschwindigkeit. Ist der Workflow proprietär und Teil Ihres Vorteils, erzwingt die Plattform Workarounds, die in Summe teurer sind als zweckgebauter Code. Eine Plattform beugt Sie ihrem Modell; Eigenentwicklung beugt die Software dem Ihren.
Konfigurieren ist nicht umsonst
Zwischen Kaufen und Bauen liegt ein dritter Weg — konfigurieren und integrieren — doch er ist nicht neutral. Eine komplexe Plattform in einen spezifischen Workflow einzupassen, mit Datenmigration und Schulung, verursacht reale Kosten noch vor der ersten Transaktion. Die Falle ist die Über-Anpassung: Starten Sie mit der empfohlenen Einrichtung und iterieren Sie anhand der Nutzungsdaten, schreiben Sie nicht alles am ersten Tag neu.
Compose: das Beste aus beidem, mit Disziplin
Der reife Ansatz ist hybrid: Marktfähigkeiten für die Standardfunktionen, verbunden über dokumentierte APIs, und interne Engineering-Kapazität konzentriert auf das, was Sie wirklich auszeichnet. Das ist die Composable-Logik (Microservices, API-first, Cloud-native, Headless): austauschbare Komponenten, die sich ändern, ohne alles mitzureißen, was an ihnen hängt.
Die Entscheidung muss strukturell sein, nicht emotional
Das Mapping der Fähigkeiten macht die Wahl lesbar: Sie sehen, wo jede Komponente auf der Achse von Genese bis Commodity sitzt, wovon sie abhängt und wohin die Evolution drängt. Die Build-vs-Buy-Linie hört auf, eine Abteilungsvorliebe zu sein, und wird zu einer verteidigbaren Architekturentscheidung.
Wie wir die Linie ziehen, Fähigkeit für Fähigkeit
Wir entscheiden nicht „Eigenentwicklung oder Plattform“ für das ganze System. Wir zerlegen das System in Fähigkeiten und führen jede durch dieselben Gates. Das Ergebnis ist eine Karte, keine Meinung.
Wir zerlegen das System in seine Fähigkeiten und verorten jede auf der Core/Commodity-Achse: was Sie differenziert, was zum Standard geworden ist. Das trennt, was eigenen Code wert ist, von dem, was Sie schlicht kaufen.
Für jede Fähigkeit prüfen wir, wie proprietär Ihr Workflow ist. 60–70 % Standard mit handhabbaren Ausnahmen: konfigurieren. Workflow, der Teil des Vorteils ist: bauen. Generischer Workflow: kaufen.
Wir berechnen die Fünf-Jahres-Kosten inklusive Wartung, Integration und Schulung — nicht nur Lizenz oder Erstangebot. Parallel messen wir die Ausstiegskosten: Datenportabilität, Exportrechte, Abhängigkeit von Integrationen.
Jede Fähigkeit erhält ein Verdikt — build, buy oder compose — und ihren Platz in der Architektur. Commodities gehen hinter dokumentierte APIs; der Differenzierer wird zu eigenem Code, mit den Daten unter Ihrer Kontrolle.
Von der Fähigkeitskarte zu einem verteidigbaren Entscheidungsraster in Wochen, nicht in einem Quartal voller Studien.
Build, Buy oder Compose: die Entscheidungs-Gates
Jede Fähigkeit läuft durch fünf Hebel. Es ist keine Punktsumme: Ein einziger Hebel kann die Entscheidung kippen (proprietäre, nicht exportierbare Daten wiegen schwerer als jede Listenpreis-Ersparnis).
| Entscheidungshebel | Drängt zu BUY / Plattform | Drängt zu BUILD / Eigenentwicklung |
|---|---|---|
| Position auf der Karte | Commodity-Fähigkeit, identisch zu den Wettbewerbern | Core-Fähigkeit, die Sie differenziert und sich schnell entwickelt |
| Prozess-Fit | Generischer Workflow, gefestigte Branchenstandards | Proprietärer Workflow; die Plattform erzwingt teure Workarounds |
| 5-Jahres-TCO | Wartung und Risiko trägt der Anbieter | Volumen und Nutzungsdauer amortisieren die Entwicklungskosten |
| Lock-in & Ausstieg | Export in offene Standards, Ausstieg aus Bequemlichkeit, API-Integrationen | Kritische Daten müssen im eigenen Besitz bleiben, unabhängig vom Anbieter |
| Time-to-Value | Wert wird jetzt gebraucht; bewährte Lösung bereits verfügbar | Der Vorteil rechtfertigt eine längere, getragene Umsetzung |
Die vier Assets, die das Raster sichert
Eine solide Build-vs-Buy-Entscheidung optimiert nicht nur die Kosten. Sie schützt, was sich, einmal verloren, nicht zurückkaufen lässt.
Datenhoheit
Die Daten, die Sie auszeichnen, bleiben Ihre — exportierbar in Standardformaten und unabhängig vom Anbieter. Keine Geisel in einem proprietären Silo, sondern ein verhandelbares Asset, das Ihnen bei der Verlängerung Spielraum gibt.
Gut investierte Engineering-Kapazität
Jede Entwicklungsstunde fließt in Ihren Wettbewerbsvorteil, nicht in eine Commodity, die der Markt bereits gelöst hat. Eigenentwicklung, wo es zählt, Markt, wo nicht.
Ausstiegsrechte
Datenportabilität, dokumentierte API-Integrationen und keine proprietäre Verdrahtung halten die Wechselkosten niedrig. Die Möglichkeit zu gehen ist es, die Sie zu fairen Bedingungen bleiben lässt.
Composable-Architektur
Austauschbare Fähigkeiten, über APIs verbunden: eine Komponente ändert sich, ohne dass der Rest einstürzt. Das System bleibt über die Zeit lebendig, kein Monolith zum Neubau.
Baue, was dich auszeichnet, kaufe, was du mit deinen Wettbewerbern teilst.
Die Fragen, die uns vor der Entscheidung gestellt werden
Ist Eigenentwicklung immer teurer als eine Plattform?
Nicht über den Lebenszyklus. Der Großteil der Softwarekosten fällt nach dem Go-live an — Wartung, Integration, Schulung. Bei einer Commodity gewinnt die Plattform, weil sie diese Kosten auf den Anbieter abwälzt. Bei einer Core-Fähigkeit mit hohem Volumen und langer Nutzungsdauer amortisiert sich die Eigenentwicklung, während der Preis einer Plattform über die Zeit steigt. Die Antwort liegt im Fünf-Jahres-TCO, nicht im Einstiegspreis.
Kann ich jetzt kaufen und später bauen?
Ja, und oft ist das der richtige Zug — solange Sie nicht in die Falle geraten. Kaufen, um schnell zu starten, ist sinnvoll, wenn die Daten in offenen Standards exportierbar bleiben und Integrationen über dokumentierte APIs laufen. Hält der Anbieter Ihre Daten in einem proprietären Format, wird aus „später“ eine teure Migration, die Sie nie durchführen. Portabilität wird bei der Unterschrift verhandelt, nicht bei der Scheidung.
Wie vermeiden wir, etwas zu bauen, das der Markt besser kann?
Indem wir jede Fähigkeit kartieren, bevor Code geschrieben wird. Ist eine Funktion zum Standard geworden — dieselbe für Sie und Ihre Wettbewerber —, ist es verbrannte Engineering-Kapazität, sie zu bauen. Eigener Code ist dem vorbehalten, was Sie differenziert und sich weiterentwickelt; alles andere wird gekauft oder über APIs komponiert. Diese Disziplin trennt eine Investition von einer Ausgabe.
Fallnotizen
Vom Problem zum Ergebnis — anonymisiert.
Die verbogene Plattform
Problem Ein Einzelhändler hatte eine Standard-E-Commerce-Plattform angepasst, bis sie sich selbst nicht mehr ähnelte: Jedes Release des Anbieters brach die Konfiguration, und „von der Stange“ war zu einem dauerhaften Entwicklungsprojekt geworden — mit der Pricing-Engine, ihrem eigentlichen Differenzierer, eingeklemmt in Zwängen, die sie nicht kontrollierten.
Methode Wir kartierten die Fähigkeiten auf der Core/Commodity-Achse: Katalog, Checkout und Zahlungen blieben als Commodities hinter dokumentierten APIs auf der Plattform; die Pricing- und Promotions-Engine, Teil des Wettbewerbsvorteils, wurde als eigener, composable verdrahteter Dienst herausgelöst.
Ergebnis Releases des Anbieters brachen das System nicht mehr, die Engineering-Kapazität ging zurück ins Pricing statt in Workarounds, und die Logik, die sie auszeichnet, wurde ihr eigener Code — austauschbar, ohne den Rest einstürzen zu lassen.
Die Daten als Geisel
Problem Ein Finanzdienstleister hielt die Kundendaten, die ihn auszeichneten, bei einem Anbieter — in einem proprietären Format ohne Export in offene Standards: Ein Wechsel war undenkbar, und bei der Verlängerung hatte der Anbieter den gesamten Spielraum, weil der Ausstieg faktisch verschlossen war.
Methode Wir wandten die Lock-in- und Datenhoheits-Gates an: Exportrechte in Standardformate zur Vertragskündigung neu verhandelt, kritische Integrationen auf dokumentierte APIs verlagert und die differenzierenden Daten zurück unter interne Kontrolle gebracht — Commodity-Funktionen blieben, wo sie waren.
Ergebnis Die Ausstiegskosten sanken so weit, dass bei der Verlängerung wieder Spielraum entstand, die Daten wurden wieder ein verhandelbares Asset statt einer Geisel, und die Möglichkeit zu gehen hielt sie zu fairen Bedingungen.
Die von Grund auf gebaute Commodity
Problem Ein Logistikbetreiber hatte Commodity-Fähigkeiten von Grund auf gebaut — Authentifizierung, Benachrichtigungen, Nutzerverwaltung — und Engineering-Kapazität auf Probleme verbrannt, die der Markt längst gelöst hatte, während die Routenplanung, ihr eigentlicher Vorteil, unterinvestiert blieb.
Methode Wir führten jede Fähigkeit durch die Wertkarte und das Fünf-Jahres-TCO: die Eigenentwicklungen der Commodities zugunsten von Marktdiensten hinter APIs ausgemustert und die Entwickler auf die Routenoptimierung konzentriert, wo Volumen und Nutzungsdauer den zweckgebauten Code amortisieren.
Ergebnis Jede Entwicklungsstunde floss zurück in den Differenzierer, die Commodity-Wartung wanderte zu den Anbietern, und die Architektur wurde composable — austauschbare Komponenten, die sich ändern, ohne den ganzen Block neu zu bauen.
Tiefer eintauchen
KI-Produktarchitektur→
Wo die Commodity endet und eigener Code beginnt, wenn das System KI-nativ ist.
RAG und Grounding→
Kaufe das Modell, baue das Grounding auf den Daten, die dich auszeichnen.
Governance der KI-Einführung→
Vor dem Vorstand verteidigbare Kriterien für die Entscheidung build, buy oder compose bei KI.