Build vs. Buy: Wann lohnt sich Eigenentwicklung?
Foto von Jens Lelie auf Unsplash
"Wir bauen das selbst, so schwer kann das nicht sein." Sechs Monate und 200.000 Euro später die Erkenntnis: Es gibt eine fertige Lösung für 500 Euro im Monat.
Das Gegenstück kenne ich genauso gut: Ein Unternehmen kauft eine Standardlösung, passt sie zwei Jahre lang an und hat am Ende mehr ausgegeben als eine Eigenentwicklung gekostet hätte. Die Anpassungen haben das Produkt so verbogen, dass jedes Update zum Risiko wird und der Anbieter die Hände hebt.
Beide Wege können richtig sein. Beide können teuer scheitern. Der Unterschied liegt nicht in der Technologie, sondern in der Entscheidungsqualität. Und genau die fehlt in den meisten mittelständischen Unternehmen, weil niemand am Tisch sitzt, der beide Seiten aus Erfahrung kennt.
Dieser Artikel zeigt, wann sich Eigenentwicklung lohnt, wann Kaufsoftware die bessere Wahl ist und wie Sie die Entscheidung systematisch treffen. Er basiert auf meiner Erfahrung aus über 20 Jahren Softwareentwicklung und technischer Beratung, in denen ich beide Wege begleitet habe, erfolgreiche und gescheiterte.
Warum diese Entscheidung so oft schiefgeht
Build vs. Buy ist eine der folgenreichsten Entscheidungen in der IT. Sie bindet Budget für Jahre, bestimmt die Flexibilität Ihrer Prozesse und beeinflusst, wie schnell Ihr Unternehmen auf Veränderungen reagieren kann. Trotzdem wird sie erstaunlich oft auf dünner Grundlage getroffen. Die Gründe dafür sind strukturell.
Das Individualisierungs-Bias
Fast jedes Unternehmen hält seine Prozesse für einzigartig. "Das gibt es so nicht am Markt." "Unsere Anforderungen sind zu speziell." "Keine Standardlösung bildet ab, was wir brauchen." In manchen Fällen stimmt das. In den meisten nicht.
Die Realität: 80 Prozent der Geschäftsprozesse in einem mittelständischen Unternehmen sind Standard. Buchhaltung, Personalverwaltung, Projektmanagement, CRM, E-Mail-Marketing. Die verbleibenden 20 Prozent, die tatsächlich individuell sind, rechtfertigen selten ein komplett eigenes System. Sie rechtfertigen individuelle Erweiterungen einer Standardlösung.
Wer dieses Bias nicht erkennt, investiert sechsstellige Beträge in die Nachbildung von Funktionen, die es für einen Bruchteil als fertige Software gibt.
Die Eisberg-Illusion
Die sichtbaren Kosten einer Eigenentwicklung, das Angebot der Agentur, die geschätzte Entwicklungszeit, sind nur die Spitze des Eisbergs. Unter der Oberfläche liegen: Wartung, Sicherheitsupdates, Serverkosten, Dokumentation, Einarbeitung neuer Mitarbeiter, Weiterentwicklung bei veränderten Anforderungen, Debugging, Performance-Optimierung und das Risiko, dass der Entwickler, der den Code geschrieben hat, irgendwann nicht mehr verfügbar ist.
In meiner Erfahrung machen die initialen Entwicklungskosten 20 bis 30 Prozent der Gesamtkosten über fünf Jahre aus. Die restlichen 70 bis 80 Prozent werden selten budgetiert, aber immer fällig.
Der Verkäufer-Effekt
Jeder, den Sie fragen, hat ein eigenes Interesse. Die Agentur empfiehlt Eigenentwicklung, weil sie davon lebt. Der SaaS-Anbieter empfiehlt sein Produkt, weil er davon lebt. Der interne IT-Leiter empfiehlt das, was er kennt und kontrollieren kann.
Niemand davon lügt. Aber niemand davon hat eine neutrale Gesamtsicht. Ohne jemanden am Tisch, der kein Verkaufsinteresse hat und beide Welten kennt, fehlt die Grundlage für eine fundierte Entscheidung. Warum genau diese neutrale Perspektive in vielen Unternehmen fehlt, habe ich in einem früheren Artikel beschrieben.
Fehlende Bewertungskompetenz
Build vs. Buy ist eine Entscheidung, die technisches Verständnis und Business-Perspektive gleichzeitig erfordert. Geschäftsführer verstehen das Business, aber nicht die technischen Implikationen. Entwickler verstehen die Technik, aber nicht die Geschäftsstrategie. Ohne jemanden, der beide Seiten verbindet, werden Entscheidungen auf Basis von Demos, Verkaufsgesprächen oder dem Zufall getroffen, wer zuerst angerufen hat.
Die wahren Kosten von Eigenentwicklung
Eigenentwicklung ist nicht grundsätzlich teuer. Sie ist teuer, wenn die Gesamtkosten unterschätzt werden. Und das passiert fast immer, weil die offensichtlichen Kosten nur einen Bruchteil des Gesamtbilds darstellen.
Initiale Entwicklung
Die erste Überraschung kommt meistens schon hier. Der typische Faktor zwischen Schätzung und Realität liegt bei 2 bis 3. Das ist keine Kritik an Entwicklern oder Agenturen, sondern ein strukturelles Problem: Anforderungen sind zu Beginn nie vollständig klar, technische Überraschungen sind unvermeidlich, und der Aufwand für Qualitätssicherung, Testing und Dokumentation wird systematisch unterschätzt.
Ein Projekt, das auf 80.000 Euro geschätzt wird, landet realistisch bei 160.000 bis 240.000 Euro. Nicht weil jemand betrogen wird, sondern weil Softwareentwicklung komplex ist und sich Anforderungen während der Entwicklung verändern.
Laufende Wartung
Jede Software braucht Pflege. Sicherheitsupdates, Bugfixes, Serverüberwachung, Datenbankoptimierung, Anpassung an neue Browserversionen oder Betriebssysteme. Erfahrungswert: 15 bis 25 Prozent der initialen Entwicklungskosten pro Jahr.
Bei einem System, das 200.000 Euro in der Entwicklung gekostet hat, sind das 30.000 bis 50.000 Euro jährlich. Dieser Posten wird bei der initialen Entscheidung fast nie budgetiert, ist aber unvermeidbar. Software, die nicht gewartet wird, verfällt. Sicherheitslücken öffnen sich, Abhängigkeiten veralten, und irgendwann funktioniert das System nicht mehr mit aktuellen Browsern oder Betriebssystemen.
Weiterentwicklung und Personalrisiko
Geschäftsanforderungen ändern sich. Neue Features werden nötig, Schnittstellen zu anderen Systemen müssen gebaut werden, regulatorische Anforderungen kommen hinzu. Jede Änderung an individueller Software erfordert Entwickler, die den Code kennen.
Hier liegt ein Risiko, das oft unterschätzt wird: Personalabhängigkeit. Wenn der Entwickler oder die Agentur, die das System gebaut hat, nicht mehr verfügbar ist, wird jede Änderung zum Abenteuer. Ein neuer Entwickler muss sich erst in einen Code einarbeiten, den er nicht kennt, der möglicherweise schlecht dokumentiert ist und dessen Architekturentscheidungen nirgendwo festgehalten sind. Das kostet Zeit und Geld, oft mehr als die eigentliche Änderung.
Rechenbeispiel: Eigenentwicklung über 5 Jahre
| Kostenart | Betrag |
|---|---|
| Initiale Entwicklung | 150.000 EUR |
| Wartung (5 Jahre, 30.000 EUR/Jahr) | 150.000 EUR |
| Weiterentwicklung (geschätzt) | 60.000 EUR |
| Infrastruktur (Server, Hosting, 5 Jahre) | 30.000 EUR |
| Gesamtkosten | 390.000 EUR |
Das initiale Angebot lautete 150.000 Euro. Die tatsächlichen Kosten über fünf Jahre sind mehr als doppelt so hoch. Das ist kein Worst Case, sondern der Normalfall.
Die wahren Kosten von Kaufsoftware
Kaufsoftware, insbesondere SaaS-Lösungen, erscheint auf den ersten Blick günstiger. Monatliche Gebühren statt hoher Einmalinvestitionen. Wartung und Updates inklusive. Schneller Start. Aber auch hier gibt es eine Realität jenseits der Preisliste.
Lizenz- und Abo-Kosten
SaaS-Preise sind nicht statisch. Anbieter erhöhen regelmäßig, typisch sind 8 bis 12 Prozent pro Jahr. Was heute 1.500 Euro im Monat kostet, kostet in fünf Jahren 2.200 Euro. Hinzu kommt: Viele Funktionen, die Sie brauchen, sind nur im Enterprise-Tier verfügbar. Die günstige Einstiegsstufe lockt, aber in der Praxis brauchen Sie fast immer die teurere Variante.
Auch die Preismodelle selbst können sich ändern. Anbieter wechseln von Flat-Rate zu nutzungsbasierter Abrechnung, streichen günstige Legacy-Tarife oder bündeln Features in teurere Pakete. Sie haben darauf keinen Einfluss.
Anpassung und Integration
Keine Standardsoftware passt sofort. Integration mit bestehenden Systemen, Konfiguration, Datenmigration, Schulung: Selbst bei einer gut passenden Lösung fallen Implementierungskosten an. Bei komplexeren Anforderungen können diese erheblich sein.
Besonders teuer wird es, wenn Sie die Software gegen ihren natürlichen Workflow verbiegen. Jede Abweichung vom Standard kostet überproportional, weil sie bei jedem Update erneut geprüft und möglicherweise angepasst werden muss. Was der Anbieter als "flexibel konfigurierbar" verkauft, ist in der Praxis oft "konfigurierbar, solange Sie es so machen wie alle anderen".
Vendor Lock-in
Mit jeder Woche, die Sie eine Software nutzen, steigen die Wechselkosten. Daten liegen im Format des Anbieters. Prozesse sind auf die Software optimiert. Mitarbeiter sind eingearbeitet. Schnittstellen zu anderen Systemen sind gebaut.
Wenn der Anbieter seine Preise verdoppelt, das Produkt einstellt oder eine Übernahme stattfindet, die die Produktstrategie verändert, stehen Sie vor einem teuren Umstieg. Und Sie stehen nicht allein: Tausende andere Kunden haben dasselbe Problem, was den Migrationsdruck erhöht und die Alternativen verteuert.
Wann Kaufsoftware teurer wird als Eigenentwicklung
Nicht jede Kaufsoftware spart Geld. Wenn Ihre Anforderungen stark vom Standard abweichen, summieren sich Anpassungskosten, Integrationsaufwand und Enterprise-Lizenzen schnell.
| Kostenart | Betrag |
|---|---|
| SaaS-Lizenz (5 Jahre, steigend) | 120.000 EUR |
| Implementierung und Customizing | 80.000 EUR |
| Jährliche Integrationskosten (5 Jahre) | 75.000 EUR |
| Schulung und Change Management | 15.000 EUR |
| Gesamtkosten | 290.000 EUR |
In diesem Szenario liegen die Kosten nahe an einer Eigenentwicklung, aber Sie besitzen am Ende nichts. Die Software gehört dem Anbieter, und wenn Sie wechseln, nehmen Sie außer Ihren Daten (hoffentlich) nichts mit.
Das Entscheidungsframework: Build, Buy oder Hybrid
Die richtige Antwort ist nicht pauschal "bauen" oder "kaufen". Sie hängt von konkreten Faktoren ab, die sich systematisch bewerten lassen.
Wann Build die richtige Wahl ist
Software ist Ihr Wettbewerbsvorteil. Wenn die Software selbst das Produkt ist oder einen echten Differenzierungsfaktor darstellt, lohnt sich Eigenentwicklung. Kein Standardprodukt kann Ihnen einen Wettbewerbsvorteil verschaffen, den Ihre Konkurrenz mit demselben Produkt ebenfalls kaufen könnte.
Anforderungen sind wirklich individuell. Nicht "wir machen das ein bisschen anders", sondern fundamental anders. Wenn keine Standardlösung 60 Prozent Ihrer Anforderungen abdeckt, ist die Anpassung einer Kaufsoftware teurer als die Entwicklung von Grund auf.
Langfristige Kontrolle ist geschäftskritisch. Wenn die Abhängigkeit von einem externen Anbieter ein inakzeptables Risiko darstellt, beispielsweise bei Unternehmen in regulierten Branchen oder mit strengen Datenschutzanforderungen, gibt Eigenentwicklung die volle Kontrolle über Code, Daten und Infrastruktur.
Internes Entwicklungsteam ist vorhanden oder geplant. Eigenentwicklung ohne eigenes Team bedeutet permanente Abhängigkeit von externen Dienstleistern. Das verschiebt das Vendor-Lock-in-Problem nur von einem Softwareanbieter auf eine Agentur.
Wann Buy die richtige Wahl ist
Standardprozesse. Buchhaltung, Personalverwaltung, CRM, Projektmanagement, E-Mail-Marketing: Für diese Bereiche existieren ausgereifteeuere Lösungen, die von tausenden Unternehmen genutzt und kontinuierlich verbessert werden. Hier selbst zu entwickeln ist fast immer eine Fehlallokation von Ressourcen.
Time-to-Market ist entscheidend. Wenn Geschwindigkeit wichtiger ist als Individualität, liefert Kaufsoftware in Wochen, was Eigenentwicklung in Monaten produziert. In schnellen Märkten kann dieser Vorsprung den Unterschied machen.
Kein internes Entwicklungsteam. Ohne eigene Entwickler sind Sie bei Eigenentwicklung dauerhaft auf externe Dienstleister angewiesen. Das ist teuer, riskant und macht Sie abhängig. Kaufsoftware wird vom Anbieter gewartet und weiterentwickelt.
Regulatorische Anforderungen. In bestimmten Bereichen (Buchhaltung, Datenschutz, Branchenstandards) sind spezialisierte Anbieter besser positioniert, um Compliance sicherzustellen, als eine individuelle Entwicklung, die Sie selbst auditieren und aktuell halten müssen.
Der Hybrid-Ansatz: Oft die beste Antwort
In der Praxis ist die Antwort häufig weder rein Build noch rein Buy. Der Hybrid-Ansatz nutzt Standardsoftware als Plattform und ergänzt sie um individuelle Module dort, wo der echte Differenzierungsbedarf liegt.
Beispiel E-Commerce: Shopify oder WooCommerce als Basis für den Standard-Onlineshop. Individuelle Produktkonfiguratoren, Schnittstellen zum ERP und branchenspezifische Logik als Eigenentwicklung. Die Plattform liefert Warenkorb, Bezahlung, Bestellverwaltung, alles Standardfunktionen. Die Differenzierung kommt aus den individuellen Erweiterungen.
Beispiel CRM: Salesforce oder HubSpot für das Kontaktmanagement. Individuelle Integrationen und Automatisierungen, die spezifische Geschäftsprozesse abbilden. Das CRM selbst muss nicht neu erfunden werden. Aber die Art, wie es mit Ihren anderen Systemen zusammenarbeitet, kann es.
Der Schlüssel: API-first denken. Kaufsoftware auswählen, die offene Schnittstellen bietet. Eigenentwicklung dort einsetzen, wo Standardfunktionen nicht ausreichen. So vermeiden Sie den Aufwand für die 80 Prozent Standardfunktionalität und investieren Ihr Budget in die 20 Prozent, die den Unterschied machen.
Drei Fragen vor jeder Entscheidung
Bevor Sie eine Build-vs.-Buy-Entscheidung treffen, sollten Sie drei Fragen beantworten. Nicht Ihre Agentur. Nicht der Softwareanbieter. Sie, mit neutraler technischer Unterstützung.
1. Ist das unser Wettbewerbsvorteil?
Die wichtigste Frage. Wenn die Software einen echten Wettbewerbsvorteil schafft, der Kunden bindet oder gewinnt, lohnt sich die Investition in Eigenentwicklung. Wenn nicht, ist Standardsoftware fast immer die bessere Wahl.
Der Test: Würden Ihre Kunden zu einem Wettbewerber wechseln, wenn dieser dieselbe Software nutzt? Wenn ja, ist es ein Differenzierungsfaktor. Wenn nein, ist es eine Standardfunktion, und die sollten Sie nicht selbst bauen.
Ein ERP-System ist fast nie ein Wettbewerbsvorteil. Ein Produktkonfigurator, der das Kundenerlebnis definiert, kann einer sein. Buchhaltungssoftware ist Standard. Ein Algorithmus, der Ihre Lieferrouten optimiert und Ihnen dadurch einen Kostenvorteil verschafft, ist es nicht.
2. Wie sieht die TCO über 5 Jahre aus?
Vergleichen Sie nicht Anschaffungskosten. Vergleichen Sie Total Cost of Ownership (TCO) über mindestens fünf Jahre. Das bedeutet: Entwicklung plus Wartung plus Weiterentwicklung plus Infrastruktur plus Personal bei Eigenentwicklung. Lizenzgebühren plus Anpassung plus Integration plus Schulung plus steigende Kosten bei Kaufsoftware.
Wer diese Rechnung aufstellt, ist entscheidend. Der Softwareanbieter wird seine Lösung günstiger darstellen. Die Agentur wird die Eigenentwicklung optimistischer schätzen. Sie brauchen jemanden, der beide Seiten realistisch bewerten kann, ohne eigenes Verkaufsinteresse.
3. Was passiert, wenn wir uns irren?
Keine Entscheidung ist perfekt. Die Frage ist, wie teuer der Irrtum wird. Bewerten Sie die Reversibilität beider Optionen.
Eigenentwicklung: Der Code gehört Ihnen. Sie können ihn anpassen, erweitern oder ersetzen. Aber ein Umstieg auf eine Kaufsoftware bedeutet trotzdem: Datenmigration, Prozessumstellung, Schulung. Der sunk-cost-Effekt ("Wir haben schon so viel investiert") verhindert oft den rechtzeitigen Wechsel.
Kaufsoftware: Ein Anbieterwechsel ist aufwändig, aber machbar. Die Daten gehören Ihnen (prüfen Sie das im Vertrag). Wenn der Anbieter sein Produkt einstellt, haben Sie ein Problem, aber nicht den Totalverlust einer gescheiterten Eigenentwicklung.
Die Faustregel: Bei Unsicherheit gewinnt die reversiblere Option. Starten Sie mit Kaufsoftware und validieren Sie, ob die Standardlösung ausreicht. Wenn nicht, haben Sie durch die Erfahrung ein viel klareres Bild Ihrer tatsächlichen Anforderungen für eine spätere Eigenentwicklung.
Warum diese Entscheidung technische Führung braucht
Build vs. Buy ist eine Entscheidung an der Schnittstelle von Technologie und Geschäftsstrategie. Der Geschäftsführer kennt die Anforderungen, aber nicht die technische Machbarkeit und die Folgekosten. Der Softwareanbieter kennt sein Produkt, aber nicht Ihre Gesamtlandschaft. Die Agentur kennt ihre Stärken, aber hat ein Interesse am Ergebnis.
Was fehlt, ist eine neutrale, technisch fundierte Gesamtsicht. Jemand, der:
- Beide Optionen ohne eigenes Verkaufsinteresse bewertet
- Die technische Machbarkeit und die Business-Implikationen versteht
- Die Fallstricke beider Wege aus Erfahrung kennt
- Die TCO-Rechnung erstellt, die alle Kosten einbezieht
- Die Reversibilität beider Optionen realistisch einschätzt
Das ist eine klassische Aufgabe für einen CTO oder technischen Berater. Nicht weil ein Geschäftsführer das nicht kann, sondern weil diese Entscheidung Expertise erfordert, die man nur durch jahrelange Erfahrung mit beiden Wegen aufbaut.
Ein konkretes Beispiel: Ein Unternehmen stand vor der Wahl zwischen einer SaaS-Plattform für 4.000 Euro im Monat und einer Eigenentwicklung, die auf 120.000 Euro geschätzt wurde. Auf den ersten Blick scheint die Eigenentwicklung nach zweieinhalb Jahren günstiger. Aber: Die Eigenentwicklung benötigte ein internes Team für die Wartung (80.000 Euro/Jahr), die Schätzung lag am Ende bei 280.000 Euro, und die SaaS-Lösung deckte 85 Prozent der Anforderungen ab. Mit einer individuellen Erweiterung für die restlichen 15 Prozent (30.000 Euro) war der Hybrid-Ansatz die klar bessere Wahl. Diese Einschätzung kam von einem externen technischen Berater, nicht vom SaaS-Vertrieb und nicht von der Agentur.
Fazit
Build vs. Buy ist keine einmalige Entscheidung, sondern ein wiederkehrendes strategisches Thema. Mit jeder neuen Anforderung, jedem neuen System, jeder Veränderung im Markt stellt sich die Frage neu. Die Antwort hängt von Ihrem Kontext ab: Ihren Ressourcen, Ihrem Geschäftsmodell, Ihrem Wettbewerbsumfeld.
Was immer gleich bleibt: Die falsche Entscheidung kostet sechsstellige Beträge und Jahre an verlorener Zeit. Die richtige Entscheidung spart genau das.
Der erste Schritt ist eine ehrliche Bestandsaufnahme. Wo steht Ihre Software-Landschaft? Welche Systeme sind Eigenentwicklung, welche Kaufsoftware? Wo gibt es Reibung? Wo zahlen Sie mehr als nötig? Wo fehlt Ihnen die Flexibilität, die Sie brauchen?
Diese Bestandsaufnahme allein bringt oft schon Klarheit. Und wenn nicht, dann liefert sie zumindest die Grundlage für eine fundierte nächste Entscheidung.
Checkliste: Ihre nächste Build-vs.-Buy-Entscheidung
- Sie haben die TCO über mindestens 5 Jahre berechnet, nicht nur die Anschaffungskosten.
- Sie haben geprüft, ob Ihre Anforderungen wirklich individuell sind oder ob Standardsoftware 80 Prozent abdeckt.
- Sie haben eine neutrale technische Bewertung eingeholt, nicht nur Angebote von Anbietern und Agenturen.
- Sie haben die Reversibilität beider Optionen bewertet.
- Sie haben geprüft, ob ein Hybrid-Ansatz möglich ist.
- Sie wissen, wer die Software langfristig wartet und weiterentwickelt.
- Sie haben die Vendor-Lock-in-Risiken bei Kaufsoftware bewertet.
Wenn Sie bei drei oder mehr Punkten unsicher sind, fehlt Ihnen die Grundlage für eine fundierte Entscheidung. Ein IT-Strategie-Check bringt Klarheit in zwei bis drei Tagen: Analyse Ihrer aktuellen Landschaft, Bewertung Ihrer Optionen, konkrete Handlungsempfehlung.
Sie stehen vor einer Build-vs.-Buy-Entscheidung und wollen sichergehen, dass Sie richtig investieren? Kontaktieren Sie mich für einen IT-Strategie-Check.