Build vs Buy: Selbst entwickeln oder Software kaufen?
Früher oder später steht jede wachsende Firma vor derselben Frage: Bauen wir diese Software selbst oder kaufen wir eine fertige Lösung? Die Frage klingt harmlos, aber Build vs Buy ist eine der teuersten Entscheidungen, die Gründer und Geschäftsführerinnen treffen. Teuer nicht nur, weil viel Geld daran hängt, sondern weil die Folgen erst zwei Jahre später sichtbar werden, wenn das Umsteuern richtig weh tut. Und interessanterweise wird sie fast immer aus den falschen Gründen entschieden.
Warum Build vs Buy so oft schiefgeht
Es gibt zwei Lieblingsfehler, und beide haben nichts mit einer nüchternen Abwägung zu tun.
Der erste ist der Stolz. "Das bauen wir selbst, das ist doch nur eine kleine App." Der Entwickler im Team hat Lust darauf, der Gründer möchte etwas Eigenes besitzen, und die Zahl 500 Euro pro Monat für ein fertiges Tool fühlt sich nach Verschwendung an. Also baut man los. Was in der Rechnung fehlt: Die 500 Euro pro Monat sind der billige Teil. Der teure Teil kommt danach.
Der zweite Fehler ist die Bequemlichkeit. "Dafür gibt es doch bestimmt ein Tool." Und dann wird eine Standardlösung gekauft, die genau den einen Prozess abbildet, der dein Unternehmen eigentlich von der Konkurrenz unterscheidet. Du presst dein Geschäft in fremde Formulare und wunderst dich, warum am Ende nichts richtig passt.
Beide Male ist die eigentliche Frage übersprungen worden. Und die lautet nicht "können wir das?", sondern "sollten wir das?".
Die eine Frage, die alles entscheidet
Bevor du über Kosten, Zeit oder Anbieter redest, klär eine einzige Sache: Ist diese Software deine Kernkompetenz oder ein Standardproblem?
Kernkompetenz heißt, hier entsteht der Grund, warum Kunden zu dir kommen und nicht zum Wettbewerber. Das ist die Software, die dein Geschäftsmodell trägt, den entscheidenden Prozess, in dem du besser sein willst als alle anderen. Wenn ein fertiges Tool das genauso gut könnte, hätten deine Mitbewerber es längst gekauft, und dein Vorsprung wäre keiner.
Ein Standardproblem ist alles andere. Buchhaltung, Zeiterfassung, Newsletter-Versand, Login, Zahlungsabwicklung, Ticketsystem. Diese Dinge lösen zehntausende Firmen auf dieselbe Weise. Es gibt keinen Wettbewerbsvorteil darin, das eigene Rechnungswesen selbst zu programmieren. Es gibt nur Aufwand, den ein spezialisierter Anbieter längst besser erledigt hat.
Die Faustregel ist unangenehm einfach: Bau das, was dich einzigartig macht. Kauf den Rest. Ein Steuerberatungsbüro baut keine eigene Datenbank, und ein Logistik-Startup mit einem cleveren Routing-Algorithmus sollte diesen Algorithmus nicht bei einem Standardanbieter mieten.
Die Gesamtkosten, die niemand rechnet
Wenn selbst gebaut werden soll, taucht meist eine Zahl auf: die Entwicklungskosten. Ein Angebot über, sagen wir, 40.000 Euro. Diese Zahl ist die kleinere Hälfte der Wahrheit.
Software ist kein Möbelstück, das man einmal kauft und dann dreißig Jahre nutzt. Software ist ein Haustier. Sie muss gefüttert werden, solange sie lebt. Rechne mit laufenden Kosten für Wartung, Fehlerbehebung, Sicherheitsupdates, Anpassungen an neue gesetzliche Vorgaben und die Weiterentwicklung, sobald sich deine Anforderungen ändern. Als grobe Orientierung: Über mehrere Jahre gerechnet übersteigt der Betrieb oft die ursprünglichen Entwicklungskosten deutlich.
Und dann ist da das Risiko, das in keiner Tabelle steht: die eine Person, die das System gebaut hat. Wenn sie geht, geht das Wissen mit. Bei einem gekauften Produkt kümmert sich ein ganzer Anbieter darum, dass es weiterläuft, auch wenn dort jemand kündigt.
Beim Kaufen sieht die Rechnung anders aus, ist aber auch nicht trivial. Zu den Lizenzkosten kommen Einführung, Schulung, gegebenenfalls Datenmigration und die laufenden Gebühren, die gern jährlich steigen. Wer hier nur auf den monatlichen Grundpreis schaut, unterschätzt die tatsächlichen Gesamtkosten genauso wie beim Selbstbauen.
Fünf Kriterien für deine Entscheidung
Wenn die Kernfrage geklärt ist und es nicht offensichtlich um eine deiner Kernkompetenzen geht, hilft ein kurzer Durchgang durch fünf Punkte.
Time-to-market. Wie schnell brauchst du eine Lösung? Kaufen bringt dich in Tagen oder Wochen ans Ziel, Bauen in Monaten. Wenn das Fenster jetzt offen ist, ist Selbstbauen oft schon deshalb die falsche Wahl, weil der Vorsprung weg ist, bevor du fertig bist.
Anpassbarkeit. Passt eine Standardlösung zu 80 Prozent zu deinem Prozess, ist das meist ein guter Deal. Passt sie nur zu 40 Prozent, biegst du entweder dein Unternehmen zurecht oder du bezahlst für einen Funktionsumfang, den du gegen dich selbst verwendest.
Lock-in. Wie leicht kommst du beim gekauften Produkt wieder raus? Bekommst du deine Daten in einem brauchbaren Format zurück, oder sitzt du in drei Jahren fest, weil der Anbieter die Preise verdoppelt und du keine Alternative hast? Ein bisschen Abhängigkeit ist normal, totale Abhängigkeit ist ein Klumpenrisiko.
Vorhandene Kapazität. Hast du überhaupt ein Entwicklungsteam, das eine selbst gebaute Lösung dauerhaft pflegen kann, ohne dass wichtigere Projekte liegen bleiben? Wenn deine Entwickler ohnehin ausgelastet sind, ist "wir bauen das selbst" oft eine Rechnung, die nie aufgeht.
Reifegrad des Marktes. Gibt es überhaupt eine ausgereifte fertige Lösung? Bei manchen Nischenproblemen existiert schlicht kein gutes Produkt. Dann erübrigt sich die Frage.
Der Mittelweg, den die meisten übersehen
Build vs Buy klingt nach einer Ja-oder-Nein-Frage, ist es aber selten. Die beste Antwort liegt in vielen Fällen dazwischen: Du kaufst eine solide, anpassbare Standardplattform und baust gezielt genau die Teile darauf, die dein Geschäft besonders machen.
Du bekommst das Fundament, das jahrelang gereift ist, ohne es selbst warten zu müssen. Für Buchhaltung, Lager, Einkauf oder CRM nutzt du den Standard. Und dort, wo dein Prozess wirklich anders ist, ergänzt du eine maßgeschneiderte Erweiterung. Genau dafür sind offene, modulare Systeme gemacht. Eine Plattform wie Odoo etwa deckt die Standardbereiche ab und lässt sich gezielt um eigene Module erweitern, ohne dass du das gesamte Geschäftssystem von Grund auf selbst schreibst.
Der Vorteil liegt auf der Hand: Du steckst deine begrenzte Entwicklungskraft nur dort hinein, wo sie einen Unterschied macht, und überlässt den langweiligen, aber notwendigen Rest denen, die ihn schon tausendfach gebaut haben.
Wie du dich nicht selbst in die Tasche lügst
Der ehrlichste Test ist auch der unbequemste. Stell dir vor, die selbst gebaute Software läuft seit zwei Jahren. Die Person, die sie gebaut hat, ist weg. Ein wichtiges gesetzliches Update steht an. Wer macht das, und was kostet es? Wenn du darauf keine ruhige Antwort hast, solltest du über Kaufen nachdenken.
Und umgekehrt: Wenn du gerade eine Standardlösung kaufen willst, die deinen wichtigsten Prozess abbildet, frag dich, ob du damit nicht genau das aus der Hand gibst, was dich eigentlich unterscheidbar macht.
Diese Entscheidungen fallen leichter mit jemandem, der schon oft auf beiden Seiten dieser Rechnung gestanden hat und weder Provision für ein Tool noch ein Interesse am möglichst großen Entwicklungsprojekt hat. Genau das ist der Sinn eines Founder- und CTO-Sparrings: eine unabhängige Zweitmeinung, bevor die Entscheidung teuer wird, nicht danach.
Wenn bei dir gerade so eine Build-vs-Buy-Frage ansteht, lass uns in einem kostenlosen Erstgespräch draufschauen. Melde dich, das erste Gespräch kostet dich nichts außer einer halben Stunde.
