Warum die Frage wichtiger ist als je zuvor
Noch vor wenigen Jahren war die Antwort meistens klar: Wenn es eine SaaS-Lösung gibt, die 80 % deiner Anforderungen abdeckt, kaufst du sie. Selbst entwickeln war teuer, langsam und riskant. Ein Projektteam aufbauen, Anforderungen spezifizieren, entwickeln, testen, deployen — das waren Monate und sechsstellige Budgets.
Mit dem Aufkommen von KI-gestützter Entwicklung hat sich die Gleichung verschoben. Tools wie Claude Code, Cursor oder Lovable ermöglichen es, funktionale Prototypen in Stunden statt Monaten zu bauen. Plötzlich ist „selbst bauen" keine Entscheidung mehr, die ein 6-köpfiges Entwicklerteam voraussetzt. Ein einzelner Mensch mit dem richtigen KI-Tool kann erstaunlich viel in kurzer Zeit umsetzen.
Aber — und das ist entscheidend — schnell bauen bedeutet nicht billig betreiben. Die wahren Kosten einer Software liegen selten in der initialen Entwicklung, sondern in Wartung, Sicherheit und Skalierung. Ein Prototyp in zwei Tagen klingt verlockend, aber wer kümmert sich um Sicherheitsupdates, wenn du längst am nächsten Projekt arbeitest? Wer fixt den Bug, der erst nach drei Monaten Nutzung auftritt?
Das 7-Kriterien-Framework
Statt nach Bauchgefühl zu entscheiden, hilft ein strukturierter Blick auf sieben Dimensionen. Für jedes Kriterium fragst du: Spricht das eher für Kaufen oder für Bauen? Am Ende des Artikels findest du eine Entscheidungsmatrix zum Ausfüllen — aber zuerst die Kriterien im Detail.
1. Kernkompetenz oder Commodity?
Die wichtigste Frage zuerst: Ist die Software Teil deines Wettbewerbsvorteils? Wenn du ein Buchhaltungstool brauchst, ist das eine Commodity — jedes Unternehmen braucht eins, keines gewinnt dadurch Kunden. Kauf eine SaaS-Lösung und spar dir die Energie für Dinge, die dich von der Konkurrenz abheben.
Anders sieht es aus, wenn die Software dein Produkt ist oder einen einzigartigen Workflow abbildet, den kein Standard-Tool kann. Ein proprietärer Algorithmus, ein branchenspezifischer Prozess, ein Kundenerlebnis, das dich differenziert — hier willst du die volle Kontrolle. Die Faustregel: Wenn deine Konkurrenten das gleiche Tool nutzen könnten und es keinen Unterschied macht, kauf es. Wenn die Software dein Differenzierungsmerkmal ist, bau sie.
2. Wie spezifisch sind deine Anforderungen?
SaaS-Produkte sind für den Massenmarkt gebaut. Sie decken die häufigsten Use Cases ab, aber nicht die Nischen. Die entscheidende Frage ist, wie viel Prozent deiner Anforderungen eine fertige Lösung tatsächlich abdeckt. Wenn 80 % reichen, kaufst du die SaaS und passt deine Prozesse leicht an — das ist fast immer günstiger als Eigenentwicklung. Wenn du die restlichen 20 % trotzdem brauchst, prüfe zuerst, ob die Lösung eine API oder ein Plugin-System hat. Oft kannst du die Lücken mit einer kleinen Eigenentwicklung schließen, ohne das ganze System selbst zu bauen.
Liegt die Abdeckung unter 50 %, wird es kritisch. Eine SaaS-Lösung zu verbiegen, die fundamental nicht zu deinem Workflow passt, kostet langfristig mehr als eine maßgeschneiderte Lösung — durch Workarounds, manuelle Prozesse und Frustration im Team.
3. Total Cost of Ownership (TCO)
Der häufigste Fehler bei dieser Entscheidung: Nur die Entwicklungskosten gegen die monatliche SaaS-Lizenz rechnen. Eine ehrliche TCO-Rechnung auf 3 Jahre enthält deutlich mehr. Auf der SaaS-Seite kommen zu den Lizenzgebühren noch Premium-Features, Integrationsaufwand und das Vendor-Lock-in-Risiko hinzu — was passiert, wenn der Anbieter die Preise verdoppelt oder den Dienst einstellt?
Auf der Eigenentwicklungsseite unterschätzen die meisten die laufenden Kosten: Hosting, Sicherheitsupdates, Dependency-Updates, Bug-Fixes und Feature-Weiterentwicklung. Eine SaaS für 50 €/Monat sind 1.800 € in 3 Jahren. Klingt nach viel — aber ein selbst gebautes Tool, das nach 12 Monaten ein Sicherheitsupdate braucht, das du 2 Tage lang debuggen musst, kommt schnell auf den gleichen Betrag. Und das ist nur ein einziger Vorfall.
4. Datenschutz, Compliance und Teamfähigkeit
Für europäische Unternehmen oft ein K.-o.-Kriterium: Wo liegen die Daten? Viele US-SaaS-Anbieter hosten in den USA — problematisch unter DSGVO. Ohne Auftragsverarbeitungsvertrag (AVV) darfst du personenbezogene Daten gar nicht verarbeiten lassen. Gesundheitsdaten, Finanzdaten oder HR-Daten erfordern besonders strenge Kontrolle. Wenn kein europäischer Anbieter mit passender Lösung existiert, kann Eigenentwicklung mit EU-Hosting die sicherere Wahl sein.
Gleichzeitig spielt das Team eine Rolle: Hast du Entwickler, die die Software nach dem Launch warten können? Die Person, die baut, muss nicht die sein, die wartet — aber irgendjemand muss es tun. Kein Entwickler im Team plus komplexe Domäne ergibt fast immer SaaS. Entwickler im Team plus überschaubare Komplexität — da kann Eigenentwicklung sich lohnen.
5. Time to Market und Skalierung
SaaS ist sofort einsatzbereit: Account erstellen, konfigurieren, loslegen. Eigenentwicklung braucht Wochen bis Monate — auch mit KI-Tools. Wenn du schnell am Markt sein musst, ist SaaS der pragmatische Start, mit Eigenentwicklung als langfristiger Option im Hinterkopf.
Bei der Skalierung dreht sich das Bild teilweise um: SaaS skaliert automatisch — du zahlst einfach mehr. Das ist komfortabel, aber die Kosten steigen linear mit der Nutzerzahl. Eigenentwicklung muss aktiv skaliert werden, gibt dir dafür aber die Kontrolle über Architektur und Kosten. Bei der Integration hat Eigenentwicklung den Vorteil, dass du die Schnittstellen selbst bestimmst — während du bei SaaS darauf angewiesen bist, dass der Anbieter die APIs liefert, die du brauchst.
Wann ist Vibe Coding eine echte Alternative?
Vibe Coding — also Software mit KI-Unterstützung entwickeln, ohne jede Zeile selbst zu schreiben — ist keine universelle Lösung. Aber es füllt eine Lücke, die vorher nicht existierte: zwischen „SaaS kaufen" und „professionell entwickeln lassen". Für bestimmte Szenarien ist es die beste Option.
Interne Tools sind der Sweet Spot: Ein Dashboard für dein Team, ein Reporting-Tool, eine einfache Datenbank-UI. Kein öffentlicher Traffic, begrenzte Nutzerzahl, überschaubare Sicherheitsanforderungen. Hier lohnt sich weder eine teure SaaS noch eine professionelle Entwicklung — Vibe Coding liefert in Tagen ein brauchbares Ergebnis. Ähnlich bei Prototypen und MVPs: Du willst eine Idee validieren, bevor du investierst. Ein funktionaler Prototyp in 2 Tagen ist mehr wert als ein perfekter Plan in 2 Monaten. Und Brücken-Lösungen — wenn die SaaS etwas nicht kann, was du brauchst, baust du eine kleine Ergänzung, statt den Anbieter zu wechseln.
Wo Vibe Coding an seine Grenzen stößt: Hohe Sicherheitsanforderungen wie Zahlungsverarbeitung oder Gesundheitsdaten, hoher öffentlicher Traffic, komplexe Geschäftslogik, die sich häufig ändert, und regulierte Branchen mit Audit-Anforderungen. Hier brauchst du professionelle Entwicklung — egal ob intern oder extern.
Die Entscheidungsmatrix
Trage für jedes der 7 Kriterien ein, ob es eher für Kaufen (K) oder Bauen (B) spricht. Am Ende zählst du aus:
Kriterium | K / B
-----------------------------|------
1. Kernkompetenz? |
2. Spezifische Anforderungen?|
3. TCO auf 3 Jahre? |
4. Datenschutz & Compliance? |
5. Time to Market? |
6. Team & Know-how? |
7. Skalierung & Integration? |
-----------------------------|------
Ergebnis: __K / __B |Ab 5x Kaufen: SaaS ist wahrscheinlich die richtige Wahl. Ab 5x Bauen: Eigenentwicklung lohnt sich. Bei 4:3 oder 3:4 ist ein Hybrid-Ansatz oft die beste Antwort — SaaS als Basis für die Standard-Funktionen, Eigenentwicklung für den Teil, der dich von der Konkurrenz abhebt. Das klingt nach einem Kompromiss, ist aber in der Praxis häufig die pragmatischste Lösung: Du profitierst von der Stabilität und Wartung einer SaaS, behältst aber die Kontrolle über den Teil, der wirklich zählt.