Jeder Unternehmer steht irgendwann in einem Budgetmeeting vor der Frage: Sollen wir das bauen oder kaufen? Es klingt nach einem Kostenvergleich. Das ist es fast nie. Die Tabelle, die eine Lizenzgebühr mit einer Aufwandsschätzung vergleicht, vergleicht zwei verschiedene Arten von Objekten — eine Ausgabe und einen Vermögenswert — als wären sie dasselbe.
Der Vergleich scheitert in beide Richtungen. Er unterschätzt die Kosten des Kaufens, weil die Lizenzgebühr die einzige Zeile ist, die es in die Tabelle schafft — die Workarounds, der Integrationskleber und die Workflow-Kompromisse schaffen es nie. Und er unterschätzt den Wert des Bauens, weil ein Vermögenswert, der jedes Quartal besser wird, nicht in eine Zelle passt, die für einen Abo-Preis gedacht war. Zwei Zahlen, beide falsch, diskutiert in einem Meeting, in dem die lauteste Stimme gewinnt.
Hier ist der Rahmen, den wir mit unseren eigenen Kunden verwenden — und mit den Unternehmen, in denen unsere eigene Beteiligung auf dem Spiel steht: Fragen Sie nicht, was billiger ist. Fragen Sie, was sich verzinst.
Gemietete Software verliert ab dem Tag der Unterschrift an Wert
Ein SaaS-Abo löst die heutige Version Ihres Problems mit der heutigen Version des fremden Produkts. Das ist oft genau richtig — Lohnabrechnung, E-Mail, CRM für einen Standard-Vertriebsprozess. Das sind Commodity-Probleme, und Commodity-Probleme verdienen Commodity-Lösungen. Sie zu kaufen ist kein Kompromiss; es ist Disziplin.
Aber achten Sie darauf, was Sie wirklich mieten: einen Workflow, entworfen für den Durchschnitt aller Kunden des Anbieters. Mit jedem Quartal, in dem Ihr Betrieb von diesem Durchschnitt abdriftet — hier eine Preisregel, dort ein Ausnahmeprozess —, zahlen Sie eine zweite, unsichtbare Gebühr: die Spreadsheet-Schicht. Exporte, erneutes Eintippen, Workarounds, "die Datei, die Sanja pflegt". Niemand budgetiert sie, und sie wächst exakt proportional dazu, wie differenziert Ihr Geschäft ist.
Die Miete hat versteckte Klauseln
Die Lizenzgebühr ist der sichtbare Teil des Preises. Die unsichtbaren Teile verdienen es, benannt zu werden, denn sie tun genau in den Momenten weh, in denen Sie es sich am wenigsten leisten können. Preise pro Nutzerplatz sind eine Steuer auf Wachstum — das Tool kostet am meisten in dem Quartal, in dem Sie am meisten einstellen. Preiserhöhungen folgen dem Lock-in — Verlängerungsangebote haben die Angewohnheit, sich zu verdoppeln, sobald Ihre Daten, Ihre Integrationen und die Gewohnheiten Ihres Teams im Produkt leben. Die Roadmap gehört nicht Ihnen — das Feature, von dem Ihr Betrieb abhängt, kann eingestellt, in eine höhere Preisstufe verschoben oder schlicht nie gebaut werden, und Ihr einziges Mittel ist ein Support-Ticket.
Dann ist da die Datengravitation. Nach drei Jahren sind die Wechselkosten eines tief eingebetteten SaaS-Tools oft höher als die Kosten, die Fähigkeit gleich selbst gebaut zu haben — nicht weil die Software gut ist, sondern weil der Ausstieg einen Export, eine Migration, eine Umschulung und ein Quartal operatives Risiko bedeutet. Lock-in ist keine Verschwörung; es ist das Geschäftsmodell. Es verdient nur eine Zeile in der Vergleichstabelle, und die bekommt es nie.
Eigene Software verzinst sich — wenn Sie die richtigen Dinge bauen
Individualsoftware verhält sich in der Bilanz und im Betrieb anders. Jeder Workflow, den sie absorbiert, jede Integration, die sie gewinnt, jede Ausnahme, die sie zu behandeln lernt, macht die nächste Verbesserung billiger. Das ist der Zinseszinseffekt — derselbe Mechanismus wie einbehaltene Gewinne, angewandt auf Prozesswissen.
Die Schleife ist konkret. Das System erfasst Ihre Daten in Ihrer Form, was aus der nächsten Integration eine Woche statt eines Monats macht. Die Integration holt einen weiteren Workflow unter ein Dach, was den nächsten Automatisierungskandidaten sichtbar macht. Jedes Inkrement landet auf dem letzten statt daneben. Nach fünf Jahren ist der Unterschied zwischen einem gemieteten Stack und einer eigenen Plattform keine Featureliste — sondern dass die eine die ganze Zeit Ihr Betriebswissen angesammelt hat und die andere die Roadmap von jemand anderem.
Die Effekte zweiter Ordnung werden unterschätzt. Neue Mitarbeiter lernen Ihren tatsächlichen Prozess kennen, nicht ein generisches Tool plus einen Ordner voller Workaround-Dokumente. Due Diligence bei einem Verkauf oder einer Finanzierungsrunde geht schneller, wenn der Betrieb in einem System lesbar ist — Käufer zahlen für Abläufe, die sie lesen können. Und die Software selbst ist ein Vermögenswert mit einem Wert — mehr, als sich über einen Stapel Abos sagen lässt.
Bauen Sie nur dort, wo Ihr Prozess das Produkt ist. Kaufen Sie überall dort, wo Ihr Prozess derselbe ist wie bei allen anderen.
Der Test ist eine einzige Frage: Wenn dieser Workflow doppelt so gut wäre wie der Branchenstandard, würden Kunden es merken? Wenn ja — Angebotsgeschwindigkeit bei einer Spedition, Schadenbearbeitungszeit bei einem Versicherer, Aufnahmeerlebnis bei einer Klinikgruppe —, dann ist dieser Workflow ein sich verzinsender Vermögenswert und verdient eigene Software. Wenn nein: Kaufen Sie die Commodity und gehen Sie weiter.
Zwei der Quadranten verdienen eine Anmerkung. "Kaufen, dann anpassen" ist der Quadrant, in dem die meisten mittelständischen Unternehmen öfter leben sollten, als sie es tun: Behalten Sie den Commodity-Kern und bauen Sie nur die dünne Schicht, die kodiert, was Sie anders macht — die Pricing-Engine auf dem Standard-CRM, die Ausnahmebehandlung auf dem Standard-ERP. Und "das Beste kaufen" ist wörtlich zu nehmen: Für Commodity-Workflows ist das Premium-Tool fast immer billiger als das billige Tool plus die Reibung, die es erzeugt.
Die Rechnung, die es tatsächlich entscheidet
Besteht der Workflow den Test, wird die Bauentscheidung zur Amortisationsfrage, und die sollte ehrlich gerechnet werden: Baukosten plus Betriebskosten, gegen eingesparte Stunden, vermiedene Fehler und freigesetzten Umsatz. In unseren eigenen Angeboten gilt: Übersteigt diese Amortisation zwölf Monate, raten wir vom Bauen ab — und wir halten diese Empfehlung schriftlich fest.
Führen Sie die Rechnung mit echten Zahlen, nicht mit Hoffnungen. Auf der Kostenseite: die Aufwandsschätzung, dann die Wartung — eine vernünftige Planungsgröße sind 15–20 % der Baukosten pro Jahr — plus Hosting und die interne Zeit, das System zu verantworten. Auf der Ertragsseite: die voll eingerechneten Stunden, die der Workflow heute verbraucht, die Kosten der Fehler, die er produziert, und der Umsatz, den schnellere Durchlaufzeiten freisetzen. Wenn die Ertragsseite von einer weichen Zeile "strategischer Wert" dominiert wird und die harten Zahlen sie nicht tragen, sagt Ihnen die Rechnung: kaufen.
Drei Fehlermodi gilt es zu vermeiden. Commodity-Software aus Stolz zu bauen — "wir sind besonders" stimmt für die Lohnabrechnung nicht, und der Eigenbau tritt gegen Produkte mit tausend Personen Vorsprung an. Differenzierende Software aus Ungeduld zu kaufen — das Abo startet schnell, und dann wächst die Spreadsheet-Schicht darum herum, bis der Geschwindigkeitsvorteil verschwunden ist. Und das Richtige mit dem falschen Zuschnitt zu bauen — eine v1, die alles abdecken will, liefert zu spät und landet in einem Betrieb, der längst aufgehört hat, an sie zu glauben. Die v1 sollte beschämend schmal sein und wirklich benutzt werden.
Die üblichen Einwände, ehrlich beantwortet
"Wir sind kein Softwareunternehmen." Müssen Sie auch nicht sein. Sie brauchen einen Verantwortlichen auf Ihrer Seite des Tisches und einen Partner, der für den Rest geradesteht — so wie Sie ein Gebäude besitzen, ohne ein Bauunternehmen zu sein. Was Sie nicht tun sollten: bauen, ohne die Wartungsfrage schriftlich zu sichern.
"Individualsoftware wird zum Altsystem." Schlecht gebaute Individualsoftware wird das. Genauso jedes SaaS-Tool, dem Sie entwachsen — nur können Sie einen Anbieter nicht refaktorieren. Software, gebaut auf langweiliger Mainstream-Technologie, dokumentiert und mit Tests abgedeckt, bleibt ein Jahrzehnt wartbar. Das ist ein Kriterium für die Anbieterauswahl, kein Argument gegen das Besitzen.
"Was, wenn der Anbieter unser Feature nächstes Jahr liefert?" Dann wird Ihr gemietetes Tool besser — für Sie und für jeden Wettbewerber, der es am selben Nachmittag mietet. Die Features, die ein Anbieter liefert, sind per Definition die, die Sie nicht differenzieren. Die Fähigkeit, wegen der Kunden Sie wählen, ist genau die, auf die Sie nicht warten können.
Wie die Entscheidung altert
Build vs. Buy ist keine Entscheidung, die man einmal trifft; es ist ein Portfolio, das man umschichtet. Ein Workflow, der vor drei Jahren Commodity war, kann heute dort liegen, wo Sie konkurrieren — Kunden-Onboarding macht diese Reise oft —, und eine Fähigkeit, die Sie 2019 gebaut haben, kann inzwischen eine Commodity geworden sein, die drei Anbieter besser verkaufen. Setzen Sie das Portfolio auf einen jährlichen Rhythmus: Fragen Sie für jedes eigene System, ob es den Zinseszins-Test noch besteht; fragen Sie für jedes nennenswerte Abo, was die Spreadsheet-Schicht darum herum inzwischen kostet.
Seien Sie so bereit, eigene Software stillzulegen, wie sie zu bauen. Ein individuelles Tool abzuschalten, dessen Workflow Commodity geworden ist, ist kein Eingeständnis des Scheiterns — es ist das Portfolio, das funktioniert. Der Fehlermodus ist Trägheit in beide Richtungen: Ihre Differenzierung zu mieten, weil Bauen riskant wirkt, oder Ihr Altsystem zu pflegen, weil es einmal teuer war. Der Bilanz ist egal, was etwas zu lernen gekostet hat; sie interessiert, was sich von hier an verzinst.
Wo Sie anfangen
Inventarisieren Sie Ihre Spreadsheet-Schicht. Jeder Workaround ist eine Stimme — Ihr Betrieb, der Ihnen sagt, wo er seinen gemieteten Tools bereits entwachsen ist. Beziffern Sie diese Stunden ehrlich, wenden Sie den Zinseszins-Test an, und die Build-vs-Buy-Entscheidung trifft sich meist von selbst. Die Liste wird länger sein als Ihr Appetit, und das ist der gesunde Zustand: Sortieren Sie nach Amortisation, bauen Sie von oben, und lassen Sie den gemessenen Ertrag jedes Projekts den Willen für das nächste finanzieren.
Und wenn ein Eigenbau die Hürde nimmt, halten Sie ihn an dem Standard fest, der den Fall für ihn gemacht hat: eine Kennzahl, benannt vor der ersten Zeile Code, funktionierende Software in Wochen statt Quartalen, und ein Zuschnitt, schmal genug, um peinlich zu sein. Eigene Software verzinst sich nur, wenn sie ausgeliefert wird, benutzt wird und weiter den Betrieb um sich herum absorbiert. Dieser Teil ist keine Strategiefrage. Er ist eine Frage der Umsetzung.