Build vs. Buy Rechner – Software kaufen oder entwickeln?
TCO-Vergleich mit Crossover-Chart · Strategie-Scoring · Klare Empfehlung
Build (Eigenentwicklung) oder Buy (Standardsoftware / SaaS kaufen)? Dieser Rechner kombiniert einen vollständigen TCO-Kostenvergleich mit einem Strategie-Scoring und zeigt im Crossover-Chart, ab welchem Jahr welche Option günstiger ist.
Bewerten Sie 5 strategische Faktoren (1 = niedrig, 5 = sehr hoch). Diese fließen neben den Kosten in die Empfehlung ein.
Build vs. Buy: Die wichtigste Software-Entscheidung im Unternehmen
„Kaufen oder selbst entwickeln?“ ist keine technische, sondern eine strategisch-finanzielle Entscheidung. Wer nur den Angebotspreis vergleicht, verliert. Entscheidend ist der TCO (Total Cost of Ownership) über die gesamte Nutzungsdauer — und die Frage: Schafft diese Software einen messbaren Wettbewerbsvorteil, oder unterstützt sie nur einen Standardprozess?
🎯 Die entscheidende Frage vor jeder Analyse
Ist dieser Prozess/diese Funktion Teil des Geschäftsmodells oder Commodity? Buchhaltung, HR-Verwaltung, E-Mail → Commodity → Buy. Algorithmus der Kernprodukt differenziert, proprietäre Datenauswertung → strategisch → Build erwägen.
Die vier Optionen — nicht nur zwei
Der Markt bietet heute mehr als nur Build oder Buy. Die vier realen Optionen:
| Option | Beschreibung | Wann sinnvoll? |
|---|---|---|
| Build | Eigenentwicklung mit internem oder externem Team | Kernkompetenz, hohe Spezifität, langfristige Differenzierung |
| Buy (SaaS/Lizenz) | Fertige Standardsoftware kaufen oder abonnieren | Commodity-Prozesse, schnelles Time-to-Market |
| Configure | Low-Code/No-Code-Plattform (Salesforce, Power Apps) | Anpassungsbedarf vorhanden, aber kein Kernprozess |
| Hybrid | Standardsoftware + Eigenentwicklung für kritische Teile | Kern = Build, Peripherie = Buy |
TCO: Die versteckten Kosten beider Optionen
| Kostenart | BUILD | BUY |
|---|---|---|
| Initial (einmalig) | Entwicklung, Testing, Deployment, Dokumentation | Lizenz/Setup, Einführung, Datenmigration, Anpassung |
| Laufend (monatlich) | Wartung, Betrieb, Hosting, IT-Personal | Abo/Lizenz, Support-Tier, Add-ons, Skalierungskosten |
| Versteckte Kosten | Scope Creep, Bug-Fixes, Feature-Nachrüstung, Recruiting | Vendor Lock-in, Prozessanpassung, Preiserhöhungen, Abhängigkeiten |
| Opportunitätskosten | IT-Kapazität monatelang gebunden | Keine strategische Differenzierung möglich |
| Exit-Kosten | Niedrig (eigener Code) | Hoch bei Lock-in (Datenmigration, Neueinführung) |
Der Crossover-Punkt: Wann wird Build günstiger?
In den meisten Analysen ist Buy am Anfang günstiger — weil die Entwicklungskosten fehlen. Irgendwann überkreuzen sich die kumulativen Kostenkurven. Dieser Crossover-Punkt entscheidet die Wahl.
Beispiel: CRM für 50 Mitarbeiter
Buy (Salesforce, ~€80/User/Monat): Einrichtung €15k + €48k/Jahr laufend = Jahr 5: ~€255k total
Build (internes Team): Entwicklung €120k + €20k/Jahr Wartung = Jahr 5: ~€220k total
Crossover: ~Jahr 3 — davor ist Buy günstiger, danach Build
Entscheidend: Brauchen wir wirklich ein Custom-CRM, oder tut Salesforce seinen Job? Wenn es nur Kontaktverwaltung ist → Buy. Wenn der Vertriebsprozess Kernkompetenz und hochspezifisch ist → Build erwägen.
Wann ist BUILD die richtige Wahl?
Nicht weil man es kann — sondern weil es strategisch Sinn ergibt. Kritische Kriterien:
| Kriterium | Bedeutung |
|---|---|
| Wettbewerbsvorteil | Software ist Teil des Produkts oder schafft messbaren Vorsprung |
| Hochspezifische Anforderungen | Kein Standardprodukt erfüllt >80 % der Anforderungen |
| Datenhoheit / Compliance | Regulatorische Vorgaben erlauben keine externe Lösung |
| IT-Kapazität vorhanden | Starkes internes Team mit freier Kapazität |
| Langfristige TCO | Crossover-Punkt liegt innerhalb der geplanten Nutzungsdauer |
Wann ist BUY die richtige Wahl?
| Kriterium | Bedeutung |
|---|---|
| Commodity-Prozess | Buchhaltung, HR, E-Mail, Kalender — kein Differenzierungspotenzial |
| Time-to-Market | Marktfenster ist eng — Eigenentwicklung dauert zu lang |
| Kein starkes IT-Team | Recruiting und Aufbau würden TCO deutlich erhöhen |
| Reife Standardlösungen | Markt hat ausgereifte Produkte mit großer Community |
| Kurzfristiger Horizont | Crossover-Punkt liegt außerhalb der Planungsperiode |
Die häufigsten Fehler bei Build vs. Buy
⚠️ Die 5 teuersten Denkfehler
1. Nur Initialkosten vergleichen — Laufende Kosten und Exit-Kosten werden systematisch unterschätzt.
2. „Wir können das selbst bauen“ — Technische Machbarkeit ≠ wirtschaftliche Sinnhaftigkeit.
3. Vendor Lock-in ignorieren — Nach 3 Jahren SaaS mit propietären Daten ist der Exit teuer.
4. Opportunitätskosten vergessen — Entwicklerzeit für internes Tool fehlt für Kernprodukt.
5. Keine Inflations-/Preisanpassung — SaaS-Preise steigen typisch 5–15 % p.a. — langfristige TCO oft massiv unterschätzt.
Häufige Fragen zu Build vs. Buy
Der Crossover-Point ist das Jahr, in dem kumulative Gesamtkosten beider Optionen gleich hoch sind. Davor ist Buy meist günstiger (niedrigere Initialkosten), danach oft Build (einmalige Entwicklung ist gedeckt, Buy zahlt weiter monatlich). Der Rechner zeigt diesen Schnittpunkt grafisch. Liegt der Crossover bei Jahr 8 und du planst 5 Jahre → Buy gewinnt. Liegt er bei Jahr 3 → Build kann sich lohnen.
Faustregel: Nutze den Zeitraum, für den du tatsächlich planst. SaaS-Tools: 3–5 Jahre (Technologie ändert sich schnell). ERP/Kerninfrastruktur: 7–10 Jahre. Wichtig: Bei Build-Entscheidungen immer mindestens 5 Jahre rechnen, da die Amortisation der Entwicklungskosten Zeit braucht. Bei SaaS auch Preiserhöhungen einkalkulieren: typisch 5–15 % p.a.
Configure = Low-Code/No-Code-Plattformen wie Salesforce, ServiceNow, Microsoft Power Apps, Airtable. Vorteile: Flexibilität ähnlich wie Build bei schnellerer Implementierung ähnlich wie Buy. Nachteile: Plattform-Lock-in oft noch stärker als bei klassischem SaaS, Kosten skalieren mit Komplexität stark. Sinnvoll wenn: Anpassungsbedarf vorhanden, aber kein Kernprozess — z.B. internes Tracking-Tool, Workflow-Automatisierung, Kundenportale.
Lock-in-Kosten = Migrations-/Exit-Kosten falls Wechsel nötig wird. Schätze: Datenmigration (Umfang der proprietären Datenformate), Re-Training der Mitarbeiter, Neulizenzierung, Anpassung von Integrationen. Bei kritischer Software mit proprietären Daten können Exit-Kosten 6–18 Monate Lizenzkosten entsprechen. Diese Kosten in die TCO einpreisen — als gewichtete Wahrscheinlichkeit eines Wechsels.
Open Source ist weder klassisches Build noch Buy — es ist eine Hybrid-Option: Lizenz meist kostenlos, aber Implementierung, Anpassung, Hosting und Support sind Eigenaufwand. TCO von Open Source wird oft massiv unterschätzt: eine Enterprise-Instanz (z.B. Kubernetes, Elasticsearch) kann mehr interne Kapazität binden als ein SaaS-Äquivalent. In den Rechner als „Build“ mit niedrigen Initialkosten, aber realen Wartungskosten eintragen.
🔗 Passende weitere Rechner
Break-Even-Rechner — wann amortisiert sich eine Investition · Kapitalwert (NPV) — Investitionsentscheidung mit Abzinsung · ROI-Rechner — Return on Investment berechnen · CAGR-Rechner — Wachstumsrate über Zeit
Vertrauen Sie unserer Expertise
Daniel Niedermayer
Geschäftsführer, Fixrechner.de
Zuletzt geprüft: April 2026
Grundlagen
- Gartner Research: Total Cost of Ownership Framework für Software-Entscheidungen
- Marsiglia: „Should You Build or Buy New Software?“ (Referenzframework)
Unsere Methodik
TCO_Build = Entwicklung + Setup + n×12×(Wartung + Betrieb). TCO_Buy = Einführung + Anpassung + n×12×(Lizenz + Support). Crossover: Schnittpunkt beider Geraden. Qualitative Score: gewichtete Summe aus 5 strategischen Faktoren.
Mehr zur Methodik
Die Qualität der Rechner ist enorm, und das kostenlos. Besten Dank.
Head of Sales & Business Development
Neben den Rechnern für den Arbeitsalltag finde ich auch die rund um die eigene Finanzplanung sehr hilfreich.
Agentur Geschäftsführerin
Ich schätze die Genauigkeit und Benutzerfreundlichkeit dieser Rechner sehr.
Fixrechner.de – „Alles ist berechenbar“. Einziger DE-Build-vs-Buy-Rechner mit Crossover-Chart, vollständigem TCO und qualitativem Strategie-Scoring in einem Tool.
Crossover-Chart
Ab welchem Jahr wird welche Option günstiger? Visuell auf einen Blick.
Strategie-Scoring
5 qualitative Faktoren fließen in die Empfehlung ein.
Datenschutz
Alle Berechnungen lokal im Browser. Keine Datenspeicherung.
Letzte Aktualisierung: April 2026