Build vs. Buy: Wann selbst bauen, wann kaufen?
Eine der häufigsten Fragen in Tech-Teams: "Sollen wir das selbst bauen oder eine fertige Lösung kaufen?" Die Antwort ist selten einfach – aber mit dem richtigen Framework wird sie systematisch.
Die wahren Kosten verstehen
Versteckte Build-Kosten
Was viele vergessen, wenn sie "Build" evaluieren:
| Kostenfaktor | Typische Unterschätzung |
|---|---|
| Initiale Entwicklung | 2-3× der ersten Schätzung |
| Wartung | 15-20% der Entwicklungskosten/Jahr |
| Infrastruktur | Skalierung, Monitoring, Security |
| Opportunity Cost | Was könnte das Team sonst bauen? |
| Onboarding | Jeder neue Dev muss eingearbeitet werden |
| Dokumentation | Oft vergessen, immer nötig |
Versteckte Buy-Kosten
Was viele vergessen, wenn sie "Buy" evaluieren:
| Kostenfaktor | Typische Unterschätzung |
|---|---|
| Integration | 2-6 Wochen pro System |
| Customization | Oft teurer als erwartet |
| Migration (später) | Lock-in kann teuer werden |
| Training | Team muss neues Tool lernen |
| Vendor Risk | Was wenn der Anbieter aufhört? |
| Kompromisse | Nicht alles passt zu 100% |
Das Build-vs-Buy Entscheidungsframework
Schritt 1: Kernkompetenz identifizieren
Build-vs-Buy-Entscheidungen spiegeln oft die Organisationsstruktur wider (Conway's Law).
Frage: Ist diese Funktionalität zentral für unser Geschäftsmodell?
| Kernkompetenz | Empfehlung |
|---|---|
| Ja, differenziert uns vom Wettbewerb | Tendenz: Build |
| Nein, Standard-Funktionalität | Tendenz: Buy |
Beispiele:
| Feature | Für E-Commerce | Für Medienunternehmen |
|---|---|---|
| Payment Processing | Buy | Buy |
| Content Management | Buy | Build (evtl.) |
| Recommendation Engine | Build (evtl.) | Build |
| User Authentication | Buy | Buy |
Schritt 2: Verfügbarkeit prüfen
Frage: Gibt es eine Lösung, die 80%+ unserer Anforderungen erfüllt?
Wenn ja:
- Integration evaluieren
- Customization-Möglichkeiten prüfen
- Total Cost of Ownership berechnen
Wenn nein:
- Gibt es Open-Source-Alternativen?
- Können wir auf bestehenden Lösungen aufbauen?
- Ist wirklich alles so speziell?
Schritt 3: Kosten berechnen
Build-Kosten Kalkulation
Entwicklungskosten (einmalig):
Entwickler × Stundensatz × geschätzte Stunden × 2,5 (Unsicherheitsfaktor)
Wartungskosten (jährlich):
Entwicklungskosten × 0,2
Infrastrukturkosten (jährlich):
Server + Tools + Monitoring
5-Jahres-TCO:
Entwicklung + (5 × Wartung) + (5 × Infrastruktur)
Beispielrechnung Build:
- Entwicklung: 2 Devs × €100/h × 400h × 2,5 = €200.000
- Wartung/Jahr: €40.000
- Infrastruktur/Jahr: €12.000
- 5-Jahres-TCO: €460.000
Buy-Kosten Kalkulation
Lizenzkosten (jährlich):
Preis pro User × Anzahl User
Integrationskosten (einmalig):
Entwickler × Stundensatz × geschätzte Stunden
Customization (einmalig + laufend):
Je nach Anforderung
5-Jahres-TCO:
Integration + Customization + (5 × Lizenz)
Beispielrechnung Buy:
- Lizenz: €500/Monat × 12 = €6.000/Jahr
- Integration: 1 Dev × €100/h × 80h = €8.000
- Customization: €15.000
- 5-Jahres-TCO: €53.000
Schritt 4: Risiken bewerten
Build-Risiken
| Risiko | Wahrscheinlichkeit | Impact | Mitigation |
|---|---|---|---|
| Scope Creep | Hoch | Mittel | Klare Specs |
| Key Person Risk | Mittel | Hoch | Dokumentation |
| Tech Debt | Hoch | Mittel | Reviews |
| Zeitverzug | Hoch | Mittel | Buffer einplanen |
Buy-Risiken
| Risiko | Wahrscheinlichkeit | Impact | Mitigation |
|---|---|---|---|
| Vendor Lock-in | Mittel | Hoch | Exit-Strategie |
| Preiserhöhung | Mittel | Mittel | Vertragsverhandlung |
| Feature Gap | Mittel | Mittel | Evaluation |
| Vendor Exit | Niedrig | Hoch | Alternativen kennen |
Schritt 5: Entscheidungsmatrix
| Kriterium | Gewichtung | Build (1-5) | Buy (1-5) |
|---|---|---|---|
| Kernkompetenz | 25% | ||
| Kosten (5J-TCO) | 20% | ||
| Time-to-Market | 15% | ||
| Flexibilität | 15% | ||
| Risiko | 15% | ||
| Team-Kompetenz | 10% |
Berechnung: Score = Σ (Gewichtung × Bewertung)
Wann Build die richtige Wahl ist
Klare Build-Indikatoren
1. Wettbewerbsvorteil
- Feature differenziert euch vom Markt
- Konkurrenten können nicht einfach kopieren
- Direkter Einfluss auf Umsatz
2. Spezifische Anforderungen
- Keine Lösung erfüllt >70% der Anforderungen
- Integration würde teurer als Build
- Langfristig viele Anpassungen nötig
3. Kontrolle kritisch
- Datensensibilität (Gesundheit, Finanzen)
- Regulatorische Anforderungen
- Performance-Kritisch
4. Ressourcen vorhanden
- Team hat Kapazität und Kompetenz
- Langfristige Wartung gesichert
- Budget für Unsicherheiten
Wann Buy die richtige Wahl ist
Verwandt: Für Enterprise-Software siehe auch unseren Make vs. Buy Software Guide.
Klare Buy-Indikatoren
1. Commodity-Funktionalität
- Standard-Problem, hundertfach gelöst
- Kein Wettbewerbsvorteil durch Eigenentwicklung
- Best Practices bereits etabliert
2. Schneller Time-to-Market
- Feature gestern gebraucht
- Lernen durch Machen wichtiger als Perfektion
- Validierung vor Investition
3. Ressourcen begrenzt
- Kleines Team, viele Prioritäten
- Keine Wartungs-Kapazität
- Fokus auf Kernprodukt
4. Expertise fehlt
- Spezielles Domänenwissen nötig
- Aufbau teurer als Einkauf
- Kein strategischer Skill
Hybrid-Strategien
Build on Buy
Bestehende Lösung als Basis, eigene Erweiterungen darauf:
[Gekaufte Basis] → [Eigene API-Layer] → [Eigene Features]
Beispiel:
- Shopify als E-Commerce-Basis
- Eigene Fulfillment-Integration
- Eigene Recommendation Engine
Buy and Extend
Fertige Lösung mit Custom Integration:
[SaaS Tool] → [Custom Webhooks] → [Eigene Automation]
Beispiel:
- HubSpot CRM
- Custom Scoring-Algorithmus
- Automatische Lead-Routing
Build to Replace
Mit Buy starten, später Build:
Phase 1: [Gekaufte Lösung] → Validierung
Phase 2: [Eigenentwicklung] → Nach Validierung
Beispiel:
- Jahr 1: Notion für Knowledge Base
- Jahr 2+: Custom Wiki (wenn Anforderungen klar)
Fallstudien
Case 1: CRM-System
Situation:
- 50-köpfiges Sales-Team
- Komplexer B2B-Sales-Cycle
- Integration mit ERP nötig
Build-Kalkulation:
- Entwicklung: €400.000
- 5J-Wartung: €200.000
- Total: €600.000
Buy-Kalkulation (Salesforce):
- Lizenz: €180.000/Jahr × 5 = €900.000
- Integration: €50.000
- Total: €950.000
Buy-Kalkulation (HubSpot):
- Lizenz: €60.000/Jahr × 5 = €300.000
- Integration: €30.000
- Total: €330.000
Entscheidung: Buy (HubSpot) Begründung: CRM ist keine Kernkompetenz, HubSpot deckt 85% ab, schneller Start.
Case 2: Recommendation Engine
Situation:
- E-Commerce mit 100.000 Produkten
- Personalisierung als Differenzierung
- Eigene Kundendaten vorhanden
Build-Kalkulation:
- Entwicklung: €150.000
- ML-Infrastruktur: €24.000/Jahr
- 5J Total: €270.000
Buy-Kalkulation:
- SaaS-Lösung: €48.000/Jahr × 5 = €240.000
- Integration: €40.000
- Keine Daten-Hoheit
- Total: €280.000 + strategischer Nachteil
Entscheidung: Build Begründung: Wettbewerbsvorteil, Daten-Kontrolle, langfristig günstiger.
Case 3: Auth-System
Situation:
- B2B SaaS Produkt
- SSO-Anforderungen
- SOC2-Compliance nötig
Build-Kalkulation:
- Entwicklung: €100.000
- Security-Audits: €30.000/Jahr
- Wartung: €20.000/Jahr
- 5J Total: €350.000
Buy-Kalkulation (Auth0):
- Lizenz: €36.000/Jahr × 5 = €180.000
- Integration: €15.000
- SOC2-konform out-of-the-box
- Total: €195.000
Entscheidung: Buy (Auth0) Begründung: Security ist zu kritisch für DIY, Compliance bereits vorhanden.
Checkliste vor der Entscheidung
Build-Checkliste
- Haben wir die Kompetenz im Team?
- Ist langfristige Wartung gesichert?
- Ist es wirklich differenzierend?
- Haben wir genug Buffer (Zeit + Budget)?
- Sind die Anforderungen klar genug?
- Gibt es wirklich keine Alternative?
Buy-Checkliste
- Erfüllt es 80%+ der Anforderungen?
- Wie ist der Vendor-Track-Record?
- Gibt es eine Exit-Strategie?
- Ist die Preisgestaltung nachhaltig?
- Wie gut ist die Integration?
- Was sagen andere Kunden?
Fazit
Build vs. Buy ist keine emotionale Entscheidung ("Wir können das besser!") und keine dogmatische ("Never build what you can buy"). Es ist eine Business-Entscheidung, die auf:
- Strategischer Relevanz – Kernkompetenz oder Commodity?
- Total Cost of Ownership – Alle Kosten über 5 Jahre
- Risikobewertung – Was kann schiefgehen?
- Ressourcen-Realität – Was können wir wirklich?
Die beste Entscheidung ist oft nicht "Build" oder "Buy", sondern eine intelligente Kombination beider Ansätze.
Du möchtest Prozesse automatisieren und fragst dich, ob n8n, Make oder Zapier das Richtige ist? Unser Tool-Vergleich hilft bei der Entscheidung.
