Wenn 5 Jahre und mehr zählen: Software selbst entwickeln oder kaufen

In den meisten Fällen ist Kaufen oder Kombinieren die bessere Wahl als eine vollständige Eigenentwicklung, ausser die Funktion ist ein klarer, für Kund:innen sichtbarer Differenzierungsfaktor und Sie können den Betrieb über fünf Jahre oder länger selbst tragen. Die Einteilung in Kaufen, Entwickeln und Kombinieren, die den Software-Einkauf in grösseren Unternehmen heute prägt, gibt es, weil reine Ja-Nein-Entscheide den Kontakt mit echten Budgets selten überleben. Es folgen eine Bewertungs-Checkliste, ein Kostenmodell und ein konkretes Beispiel, wie das Modell in einem echten Projekt angewendet wurde.

---

Kurz zusammengefasst:

• Der Kauf einer SaaS-Lösung ist in der Regel wirtschaftlicher, wenn es um kleine Nutzerzahlen oder einen schnellen Start geht, besonders wenn ein Anbieter die meisten benötigten Funktionen schon abdeckt.

• Die langfristigen Betriebskosten einer Eigenentwicklung übersteigen die anfängliche Ersparnis oft, sobald Wartung, Sicherheit und der Erhalt von Wissen eingerechnet sind. Dann ist Kaufen mitunter günstiger.

• Steht die Markteinführung in 30 bis 90 Tagen an, spricht das stark für den Kauf: Entwicklungszeiten liegen häufig über dem, was der Betrieb verkraftet, und Teams ohne tiefe technische Ressourcen riskieren Lücken im Tagesgeschäft.

• Fehlerhafte Kostenvergleiche, etwa Schätzungen für das erste Entwicklungsjahr gegen mehrjährige SaaS-Verträge, unterschätzen die echten Entwicklungskosten und führen zu schlechten Entscheiden.

• Eine gewichtete Bewertungsmatrix macht den Entscheid zwischen Kaufen, Entwickeln und Kombinieren objektiv, weil sie Differenzierung, Gesamtkosten, Integrationsaufwand und Zeit bis zum Start berücksichtigt.

---

Software selbst entwickeln oder kaufen: das Modell Kaufen, Entwickeln, Kombinieren

Drei Kategorien deckenpraktisch jeden Beschaffungsentscheid ab, und sie zu verwechseln ist der häufigste Weg, Geld zu verbrennen.

Kaufen heisst, eine SaaS-Lösung oder Standardsoftware für eine Funktion einzusetzen, die längst zur Massenware geworden ist. Lohnbuchhaltung, CRM, Ticketing, E-Mail-Infrastruktur. Andere haben dieses Problem bereits besser gelöst, als es Ihr Team im ersten Versuch schaffen wird.

Entwickeln heisst, eigene Software zu schreiben, weil die Funktion zum Kern Ihres Wettbewerbsvorteils gehört. Wenn genau diese Funktion der Grund ist, warum Kund:innen Sie und nicht die Konkurrenz wählen, dann legen Sie Ihren Differenzierungsfaktor in die Produkt-Roadmap eines Anbieters, sobald Sie ihn mieten.

Kombinieren heisst, das standardisierte Fundament zu kaufen und darauf eine dünne, differenzierende Schicht selbst zu bauen. Dieses Muster gewinnt in der Praxis. Branchenanalysen, die auf dem Buy/Build/Blend framework aufbauen, zeigen: Der grösste Teil der Software-Ausgaben in Unternehmen fliesst in gemischte Architekturen, nicht in reine Eigenentwicklung und nicht in reinen Kauf.

Die Ja-Nein-Sicht, die viele Anbieter-Pitches und interne Debatten prägt, führt in die Irre, weil sie unterstellt, jede Funktion liege an einem der beiden Extreme. Die meisten liegen es nicht. Ein Logistikunternehmen kauft vielleicht die Buchhaltungsplattform vollständig ein, entwickelt eine eigene Routing-Engine, weil das das Produkt ist, und kombiniert ein Support-Tool mit einer eigenen API-Schicht, die Echtzeitdaten in die Preisgestaltung zurückspielt.

Ein paar Faustregeln, wenn Sie Ihre eigene Liste an Funktionen sortieren:

• Hat ein System relativ wenige tägliche Nutzer:innen, ist Kaufen oft besser als Entwickeln. Die Wirtschaftlichkeit von Individualsoftware lässt sich in dieser Grössenordnung selten begründen.

• Lässt sich ein Arbeitsablauf mit einer bestehenden Plattform schnell starten, entscheidet oft schon dieser Zeitdruck für den Kauf.

• Deckt eine SaaS-Lösung den Grossteil der benötigten Funktionen ab, entwickeln Sie nur den fehlenden Teil, statt das ganze System neu zu bauen.

Wie vergleichen Sie die echten Kosten von Entwickeln und Kaufen?

Vergleiche der Gesamtkosten (Total Cost of Ownership, TCO) scheitern meist daran, dass Teams eine Schätzung für das erste Entwicklungsjahr gegen einen mehrjährigen SaaS-Vertrag stellen. Das ist kein fairer Vergleich, und es ist der schnellste Weg zum falschen Entscheid.

Ein belastbares TCO-Modell für die Eigenentwicklung umfasst: Vollkosten der Entwickler:innen (nicht nur den Grundlohn), Infrastruktur und Hosting, laufende Wartung und Updates, Sicherheitsprüfungen sowie die späteren Kosten für den Ersatz der einen Person, die das System versteht, wenn sie geht. Werkzeuge wie Betlog helfen dabei, diese Kosten zu verfolgen und die Rendite verlässlich zu messen. Für den Kauf braucht das Modell: Lizenz- oder Abo-Gebühren über die gesamte Vertragsdauer, Kosten für Integration und Migration, internen Personalaufwand für die Verwaltung des Tools, Grenzen der Anpassbarkeit, die zu Umwegen zwingen, und Ausstiegskosten, falls Sie den Anbieter je wechseln müssen. Das KORE1 five-number framework argumentiert, dass der Vergleich der Vollkosten über drei Jahre und der Zeit bis zum Nutzen den genauen Entscheid von einem nachträglich schöngerechneten unterscheidet.

Wo die Zahlen tatsächlich kippen: Ein mittelgrosses Unternehmen schätzt die Entwicklung eines eigenen Planungstools im ersten Jahr auf USD 180'000, gegenüber USD 60'000 SaaS-Gebühren pro Jahr. Drei Jahre lang sieht Kaufen günstiger aus. Rechnen Sie aber die Wartungszeit von zwei erfahrenen Entwickler:innen dazu, alle 18 Monate eine Sicherheitsprüfung und die entgangene Arbeit dieser Leute am eigentlichen Produkt, verschiebt sich der Kipppunkt um Jahre. Manchmal kommt er nie.

Typische Rechenfehler, die Sie prüfen sollten, bevor Sie der Finanzabteilung einen TCO-Vergleich vorlegen:

• Die Entwicklungskosten der ersten Version gegen den SaaS-Preis im fünften Jahr stellen, was die kumulierten Anbieterkosten zu tief ansetzt.

• Die Vollzeitstelle ignorieren, die es braucht, um ein «einfaches» SaaS-Tool einzurichten und zu pflegen.

• Integrationskosten als Einmalaufwand behandeln, obwohl sie mit jeder API-Änderung wiederkehren.

Warum die Zeit bis zum Markt oft wichtiger ist als die ganze Debatte

Geschwindigkeit verändert die Rechnung auf eine Weise, die keine Tabelle erfasst. Ein Unternehmen, das Kapital verbrennt oder mit der Konkurrenz um den Markt rennt, kann sich keinen Entwicklungszyklus von 18 Monaten leisten, so attraktiv die langfristige Kostenkurve auch aussieht. Jeder Monat ohne die fehlende Funktion ist ein Monat mit entgangenem Umsatz, stockendem Onboarding oder einem Wettbewerber, der aufholt.

Braucht ein Unternehmen eine Funktion innerhalb von 30 bis 90 Tagen im Einsatz, gewinnt der Kauf fast immer, unabhängig davon, was das TCO-Modell über fünf Jahre sagt. Practitioner guidance on core-versus-context decisions formuliert es unmissverständlich: Wenn sich das Marktfenster schliesst, schlägt Geschwindigkeit jede theoretische Kostenüberlegenheit.

Dazu kommt das Kapazitätsproblem. Teams ohne breites Entwicklungsteam schaffen eine erste Version, haben aber selten die Kapazität, die lange Reihe von Sonderfällen, Fehlerbehebungen und Integrationen danach zu pflegen. Diese operative Lücke ist oft der eigentliche Grund, warum eine «erfolgreiche» Eigenentwicklung nach zwei Jahren teuer wird.

Die versteckten Kosten technischer Altlasten in Eigenentwicklungen

Schlechte Softwarequalität hat einen belegten, enormen Preis. Der CISQ’s 2022 report zeigt, dass mangelhafte Software und technische Altlasten die US-Wirtschaft mit mehreren Billionen Dollar belasten, hauptsächlich getrieben von langfristigen Betriebs- und Wartungskosten und nicht von der ursprünglichen Entwicklung.

Diese Zahl ist hier relevant, weil sie die Lücke offenlegt zwischen dem, was eine Entwicklung bis zum Start kostet, und dem, was es kostet, sie am Leben zu halten. Ein System, das eine einzelne externe Person oder ein kleines internes Team gebaut hat, wird oft zum Risiko, weil das Wissen an einer Person hängt: Geht sie, geht das Wissen mit, und jede weitere Fehlerbehebung dauert länger und kostet mehr. Dazu kommen zwingende Sicherheitsupdates, regulatorische Anpassungen und Framework-Aktualisierungen. So überholt die Wartungsrechnung die ursprünglichen Entwicklungskosten innerhalb weniger Jahre still und leise.

Drei Massnahmen senken dieses Risiko deutlich: erfahrene technische Aufsicht ab dem ersten Tag (nicht erst beim Start), ein Wartungsbudget, das vor dem ersten Release festgelegt wird und nicht nach dem ersten Ausfall, sowie dokumentierte Verantwortlichkeiten für den Code, damit das Wissen nicht in einem einzigen Kopf liegt.

Praxistipp: Planen Sie die Wartung jährlich als festen Prozentsatz der ursprünglichen Entwicklungskosten ein, und zwar bevor Sie das Projekt freigeben. Wenn die Finanzabteilung diesen Posten nicht im Vorfeld genehmigt, ist die Entwicklung nicht vollständig kalkuliert.

Eine Bewertungs-Checkliste für Ihren eigenen Entscheid

Eine gewichtete Bewertungsmatrix macht aus einer politischen Debatte eine sachliche. Bewerten Sie jede in Frage kommende Funktion auf einer Skala von 1 bis 5 nach den folgenden Kriterien und multiplizieren Sie mit der Gewichtung, um die Gesamtpunktzahl zu erhalten.

1. Wettbewerbsvorteil (Gewicht 3): Prägt diese Funktion direkt, warum Kund:innen Sie wählen?

2. Erfahrene Entwicklungskapazität (Gewicht 2): Haben Sie Leute, die das über Jahre bauen und pflegen können, nicht nur über Monate?

3. Neuartigkeit (Gewicht 2): Gibt es überhaupt eine passende Standardlösung, oder würden Sie etwas erzwingen, das nicht passt?

4. Zeitdruck bis zum Start (Gewicht 3): Brauchen Sie das in weniger als 90 Tagen im Einsatz?

5. Funktionslücke der SaaS-Lösung (Gewicht 2): Welchen Anteil der benötigten Funktionen deckt das beste Angebot tatsächlich ab?

6. Integrationsaufwand (Gewicht 1): Mit wie vielen bestehenden Systemen muss das sprechen?

7. Regulierung und Datenstandort (Gewicht 2): Gibt es rechtliche Vorgaben, die die Auswahl an Anbietern einschränken?

8. Gesamtkosten über fünf Jahre (Gewicht 3): Welche Option gewinnt, wenn Wartung, Administration und Ausstiegskosten eingerechnet sind?

9. Kostensenkung durch KI in der Entwicklung (Gewicht 1): Verkürzen moderne KI-gestützte Werkzeuge Ihre Entwicklungszeit für genau diese Funktion spürbar?

Addieren Sie die gewichteten Punkte. Tiefe Summen sprechen für Kaufen, mittlere für Kombinieren, und hohe Summen, getrieben vor allem von Wettbewerbsvorteil und Gesamtkosten, sprechen für Entwickeln. Bevor Sie sich für ein Extrem entscheiden, empfiehlt das Modell von Techsy, mit einem echten Anbieter einen kurzen, bezahlten Machbarkeitsnachweis mit Ihren echten Daten durchzuführen. Wenn zwei Anbieter diesen Test nicht bestehen, ist das ein echtes Zeichen dafür, dass Sie selbst entwickeln müssen.

Fallstudie von Ampersand: das Modell angewendet auf Repa Immobiliare

Das Projekt Repa Immobiliare zeigt anschaulich, wie ein kombinierter Entscheid in der Praxis aussieht. Ein Immobilienportfolio, das bisher auf Papier verwaltet wurde, brauchte ein System, um Objektdaten und interne Abläufe zu digitalisieren, ohne von anfälliger, dauerhaft online verfügbarer Infrastruktur abzuhängen. Ampersand Labs griff weder automatisch zur vollständigen Eigenentwicklung noch zu einer starren Standardplattform. Stattdessen schnitt das Team eine gezielt gebaute Lösung auf die tatsächlichen Rahmenbedingungen des Kunden zu und behielt die Architekturentscheide von der ersten Besprechung an bei erfahrenen Entwickler:innen.

Diese Erfahrung zahlte sich vor allem langfristig aus. Die Entscheide am Anfang, über Datenhoheit, Funktionsfähigkeit ohne Internet und darüber, was einfach bleiben soll und was individuell gebaut wird, bestimmen genau, ob ein System nach achtzehn Monaten neu geschrieben werden muss oder einfach leise weiterläuft.

Was Sie mitnehmen können, wenn Sie vor einer ähnlichen Weggabelung stehen:

• Wenn eine Anbieter-Demo Ihren schwierigsten Sonderfall im ersten Gespräch nicht beantworten kann, verlangen Sie einen bezahlten Machbarkeitsnachweis, bevor Sie den Kauf ausschliessen.

• Wenn Sie zur Eigenentwicklung tendieren, fragen Sie, ob ein kurzer zweiwöchiger Entwicklungssprint die zentrale Annahme prüfen kann, bevor Sie sich auf ein Mandat über mehrere Monate festlegen.

Drei Regeln für einen ehrlichen Entscheid

Bauen Sie den Burggraben, kaufen Sie die Leitungen, und bewerten Sie, bevor Sie sich emotional für eine Seite entscheiden. Die meisten Teams machen es umgekehrt: Sie entwickeln die langweilige Infrastruktur, weil sich das produktiv anfühlt, und kaufen dann den Differenzierungsfaktor ein, weil eine Anbieter-Demo poliert aussah. Gehen Sie die gewichtete Checkliste vor der ersten Planungssitzung durch, nicht danach, wenn schon jemand einen Favoriten hat. Entscheiden soll die Rechnung, nicht die Eigendynamik.

Wie Ampersand Labs Sie bei diesem Entscheid unterstützt

Eine ehrliche Analyse zwischen Entwickeln und Kaufen braucht Zeit, die den meisten Produktteams zwischen zwei Sprints fehlt. Genau dort verdient ein strukturierter Entscheidungs-Workshop seine Kosten zurück. Ampersand Labs führt diese Sitzungen von Anfang an mit erfahrenen Entwickler:innen im Raum durch, nicht mit Juniorpersonal, das Entscheide nach oben weiterträgt. So wird die Bewertungsmatrix an echten technischen Rahmenbedingungen geprüft und nicht an Vermutungen.

Von dort führt der Weg meist über einen klar abgegrenzten MVP für die differenzierende Schicht, KI-Automatisierung dort, wo sie die Entwicklungszeit wirklich verkürzt, und monatliche Wartung, damit die lange Reihe von Updates und Aktualisierungen nicht auf einer einzigen überlasteten Person landet. Wenn Ihre Organisation zwischen einem Anbietervertrag und einem Entwicklungsangebot feststeckt: Vereinbaren Sie einen Entscheidungs-Workshop mit Ampersand Labs und lassen Sie die Bewertungsmatrix auf Ihre echten Zahlen anwenden, bevor Sie irgendetwas unterschreiben.

Quellen

• CISQ’s 2022 report

• Buy/Build/Blend framework

• KORE1 five-number framework

Häufige Fragen

Was bedeutet «selbst entwickeln oder kaufen»?

Der Entscheid zwischen Entwickeln und Kaufen ist der Prozess, in dem Sie wählen, ob Sie eigene Software intern entwickeln oder eine bestehende kommerzielle Lösung beziehungsweise SaaS-Lösung erwerben, um einen geschäftlichen Bedarf zu decken.

Was ist die Strategie «Kaufen und Entwickeln»?

Kaufen und Entwickeln, oft als Kombinieren bezeichnet, heisst, Standardsoftware für gängige Funktionen zu kaufen und eigenen Code nur für jene Funktionen zu schreiben, die Ihr Produkt oder Ihre Dienstleistung direkt von anderen abheben.

Was heisst «entwickeln» im Software-Kontext?

Bei Software-Entscheiden bedeutet «entwickeln», eine eigene Anwendung oder Funktion intern oder mit einem Partner zu bauen, statt ein bestehendes Produkt zu lizenzieren.

Woran erkenne ich, ob eine Funktion ein echter Wettbewerbsvorteil ist?

Fragen Sie sich, ob Kund:innen sich genau wegen dieser Funktion für Sie entscheiden. Wenn ihr Wegfall nichts daran ändern würde, warum man Sie wählt, ist sie Rahmen und nicht Differenzierung, und Kaufen ist meist sinnvoller.

Ist es günstiger, Software selbst zu entwickeln oder zu kaufen?

Das hängt vom Zeithorizont ab: Kaufen ist im ersten Jahr üblicherweise günstiger, aber ein Vergleich der Gesamtkosten über fünf Jahre, inklusive Wartung und Administrationsaufwand, kann das Ergebnis umkehren, je nach Nutzungsumfang und Preismodell des Anbieters.

Empfohlen

• MVP-, Web- und Mobile-App-Entwicklung in Zürich

• Software-Wartung in Zürich, monatliche Betreuung

• Repa Immobiliare: ein Immobilienportfolio weg vom Papier, mit Software, die nie online geht.

• Von der Idee zum Produkt, Lovable und No-Code