Make or Buy bei Software: Ein Entscheidungsrahmen für Startups

Kurz gefasst: Bauen Sie selbst, was Ihr Produkt von der Konkurrenz unterscheidet, und kaufen Sie alles andere. Login, Zahlungsabwicklung, E-Mail-Versand oder Buchhaltung sind gelöste Probleme, für die es ausgereifte Dienste gibt. Eigene Softwareentwicklung lohnt sich dort, wo Ihr Geschäftsmodell einen Ablauf verlangt, den Standardsoftware nicht abbildet, oder wo die Abhängigkeit von einem Anbieter zum Geschäftsrisiko würde.

Warum die Make-or-Buy-Entscheidung für Startups so wichtig ist

Ein Startup hat wenig Zeit und wenig Entwicklerkapazität. Jede Woche, die in ein selbst gebautes Rechnungsmodul fließt, fehlt beim eigentlichen Produkt. Umgekehrt kann ein zu früh gekauftes Tool später teuer werden, wenn es die Kernfunktion einschränkt oder die Preise mit wachsender Nutzerzahl steigen. Die Entscheidung fällt selten einmal für immer. Sie stellt sich bei jeder neuen Funktion neu, und ein klarer Rahmen spart viele Diskussionen.

Ein Entscheidungsrahmen in vier Fragen

Unterscheidet uns diese Funktion vom Wettbewerb?

Das ist die wichtigste Frage. Ein Logistik-Startup, dessen Vorteil in der Routenplanung liegt, sollte diesen Algorithmus selbst entwickeln. Die Benutzerverwaltung derselben Plattform ist dagegen Infrastruktur. Hier hilft eine ehrliche Liste: Wofür bezahlen Kunden Sie wirklich? Alles, was nicht auf dieser Liste steht, ist ein Kandidat zum Kaufen.

Was kostet die Lösung über mehrere Jahre?

Lizenzpreise sind leicht zu vergleichen, die Gesamtkosten nicht. Bei gekaufter Software kommen Kosten pro Nutzer, Aufpreise für höhere Tarife und der Aufwand für Integration und Anpassung hinzu. Bei Eigenentwicklung sind es Wartung, Sicherheitsupdates, Hosting und das Wissen, das an einzelnen Entwicklern hängt. Rechnen Sie beide Varianten für einen realistischen Zeitraum durch, und rechnen Sie die Wartung bei Eigenentwicklung immer mit ein. Unser Beitrag zum Business Case für Individualsoftware zeigt, wie Sie das strukturiert angehen.

Lässt sich die Lösung sauber integrieren?

Gute SaaS-Produkte haben eine dokumentierte API, Webhooks und Exportfunktionen. Fehlen diese, entstehen Datensilos und Handarbeit. Prüfen Sie vor dem Kauf, ob Sie Ihre Daten jederzeit vollständig exportieren können und ob die API die Abläufe unterstützt, die Sie brauchen.

Wie abhängig machen wir uns?

Abhängigkeit ist nicht per se schlecht, aber sie muss bewusst eingegangen werden. Kritisch wird es, wenn ein Anbieter Preise oder Bedingungen ändern kann und Ihr Kernprodukt dann stillsteht. Für deutsche Unternehmen kommt der Datenschutz hinzu: Wo werden die Daten gespeichert, gibt es einen Auftragsverarbeitungsvertrag, und ist eine Verarbeitung in der EU möglich?

Der Mittelweg: kaufen und erweitern

In der Praxis ist die Antwort oft beides. Sie nutzen einen Standarddienst als Fundament und entwickeln die eigene Logik darum herum. Beispiele: Authentifizierung über einen Anbieter wie Auth0, Clerk oder Supabase Auth, Zahlungen über Stripe, Inhalte über ein Headless CMS, und die eigentliche Produktlogik als eigene Webanwendung. Auch ein CRM lässt sich so behandeln. Wann ein Standard-CRM nicht mehr reicht, beschreiben wir im Artikel über individuelle CRM-Entwicklung.

No-Code-Tools gehören ebenfalls in diese Abwägung. Für interne Werkzeuge und erste Prototypen sind sie oft die schnellste Option. Wo ihre Grenzen liegen, lesen Sie im Vergleich No-Code oder Individualentwicklung.

Wann sich die Entscheidung umkehrt

Was in der MVP-Phase richtig war, kann ein Jahr später falsch sein. Typische Signale für einen Wechsel vom Kaufen zum Bauen: Die Kosten des Tools wachsen schneller als der Umsatz, das Team baut immer mehr Umwege um fehlende Funktionen, oder Kunden verlangen eine Funktion, die nur mit eigener Logik möglich ist. Umgekehrt lohnt es sich, eine selbst gebaute Komponente abzulösen, wenn sie viel Wartung frisst und keinen Wettbewerbsvorteil mehr bringt. Halten Sie Ihre Architektur deshalb so, dass einzelne Bausteine austauschbar bleiben, etwa durch eine eigene Schnittstellenschicht zwischen Produkt und externem Dienst.

Häufige Fragen (FAQ)

Ist Eigenentwicklung für ein Startup nicht immer zu teuer?

Nicht, wenn sie sich auf den Kern beschränkt. Teuer wird es, wenn Startups auch Infrastruktur selbst bauen, die es fertig gibt. Ein schlankes MVP kombiniert gekaufte Dienste mit einem kleinen, selbst entwickelten Kern und kommt so schnell an den Markt.

Woran erkennen wir, dass ein SaaS-Tool nicht mehr passt?

Wenn das Team regelmäßig Daten von Hand überträgt, wenn Workarounds zur Routine werden oder wenn die Lizenzkosten mit jedem neuen Kunden spürbar steigen. Dann lohnt eine neue Rechnung mit beiden Varianten.

Wie vermeiden wir einen Lock-in beim Kauf?

Prüfen Sie vor Vertragsabschluss die Exportmöglichkeiten und die API. Kapseln Sie den Anbieter in Ihrem Code hinter einer eigenen Schnittstelle, damit ein späterer Wechsel nur eine Stelle betrifft.

Kann man erst kaufen und später selbst bauen?

Ja, und das ist oft der vernünftigste Weg. Ein gekauftes Tool hilft, die Anforderungen im echten Betrieb kennenzulernen. Die spätere Eigenentwicklung basiert dann auf Erfahrung statt auf Annahmen.

Fazit

Die Make-or-Buy-Frage beantworten Sie am besten pro Funktion und nicht für das ganze Produkt. Wer seine Kernkompetenz klar benennt, kauft den Rest ohne schlechtes Gewissen und investiert die Entwicklungszeit dort, wo Kunden den Unterschied spüren. Wenn Sie den Kern Ihres Produkts entwickeln möchten, sprechen Sie mit uns über individuelle Webentwicklung.