Build vs. Buy wird im Konferenzraum entschieden und im Code bezahlt. In der Präsentation stehen Lizenzkosten gegen Projektbudget, in der Realität stehen Webhook-Retries gegen technische Schuld. Wer die Entscheidung nur betriebswirtschaftlich rechnet, übersieht die Posten, die drei Jahre später das Backlog dominieren.
Die strategische Seite dieser Frage haben wir bereits beantwortet: Differenzierung entscheidet, nicht der Preis. Dieser Artikel nimmt die andere Perspektive ein. Angenommen, die strategische Achse ist geklärt: Woran erkennst du als Techniker, ob Bauen oder Kaufen die richtige Antwort ist?
Es gibt drei Kostenposten, die in kaum einem Business Case auftauchen und trotzdem den Ausschlag geben: die Integrationsfläche, den Exit-Pfad und den Glue-Code. Danach bleibt nur noch eine Frage offen, und die handelt von Menschen, nicht von Technik.
Die Featureliste lügt: Integrationsfläche ist das eigentliche Preisschild
Kein SaaS-Produkt lebt allein. Es muss mit deinem Shop sprechen, mit deinem ERP, mit deinem Identity Provider, mit deinem Data Warehouse. Jede dieser Nähte ist Code, den du schreibst, testest und betreibst, egal ob das Produkt gekauft ist oder nicht.
Deshalb ist die erste Engineering-Frage nicht „Was kann das Tool?", sondern: Wie viele Integrationspunkte hat es zu meinen Kernsystemen, und wie gut sind sie? Eine saubere, versionierte REST-API mit Webhooks, Idempotenz-Unterstützung und brauchbaren Sandboxes macht ein gekauftes Produkt billig. Eine CSV-Schnittstelle mit nächtlichem Batch-Export macht es teuer, auch wenn die Lizenz nur 49 Euro im Monat kostet.
Nicht das Produkt kostet, sondern die Naht. Zwei Integrationspunkte mit guter API schlagen fünf mit schlechter, und ab einer gewissen Zahl schlechter Nähte ist die Eigenentwicklung nicht Luxus, sondern die billigere Architektur.
Lock-in ist kein Gefühl, sondern ein Datum
Vendor-Lock-in klingt abstrakt, bis der Anbieter ein Feature abschaltet, auf dem deine Anpassungen laufen. Shopify hat seine Scripts zum 30.06.2026 endgültig eingestellt; wer Checkout-Logik darauf gebaut hatte, musste auf Shopify Functions migrieren, ob es in die eigene Roadmap passte oder nicht. Das ist der Kern des Problems: Bei gekaufter Software erbst du die Roadmap des Anbieters, seine Deprecations und seine Preispolitik.
Letztere ist seit Jahren in Bewegung. Salesforce hat seine Listenpreise 2023 um 9 % und im August 2025 erneut um 6 % erhöht, quer durch den Markt wandern AI-Features in teurere Bundles, die beim Renewal fällig werden. Und selbst die Modelle dahinter stehen nicht still: Nach dem Experiment mit reinem Consumption-Pricing ist Salesforce bei seinen AI-Agenten zurück bei Seat-basierten Lizenzen mit Credit-Kontingenten. Ein Preis, den du heute vergleichst, ist in drei Jahren ein anderer, und womöglich in einer anderen Einheit.
Die Engineering-Antwort darauf heißt Exit-Pfad. Prüfe vor dem Kauf drei Dinge: Bekommst du deine Daten vollständig und in einem offenen Format heraus? Gehört dir das Schema oder nur ein Export? Und wie viele Personentage kostet ein Wechsel realistisch? Wenn die dritte Antwort „unbekannt, vermutlich viele" lautet, ist der Lizenzpreis nicht der Preis.
Glue-Code ist auch Software
Der zweitgrößte Denkfehler in Make-or-Buy-Rechnungen: „Buy" bedeutet angeblich null Engineering. Tatsächlich verschiebt es das Engineering nur. Statt Fachlogik schreibst du Synchronisation: Mappings zwischen Datenmodellen, Retry-Logik für Webhooks, Rate-Limit-Handling, Monitoring für einen Dienst, dessen Innenleben du nicht siehst.
Der Klassiker sieht so aus: Der Anbieter stellt die Struktur seiner Webhook-Payload um, angekündigt in einem Changelog, den niemand abonniert hat. Die Bestellübertragung läuft weiter, nur eben mit leeren Feldern. Aufgefallen ist so etwas schon manchem Team erst, als die Buchhaltung fragte, warum im ERP die Steuersätze fehlen. Der Fix dauert zwei Stunden, die Aufräumarbeit zwei Wochen.
Genau dieser Glue-Code hat unangenehme Eigenschaften. Er ist selten getestet, weil er „nur Integration" ist. Er gehört niemandem, weil er zwischen zwei Systemen lebt. Und er bricht zu Zeitpunkten, die der Anbieter bestimmt, nicht du.
Auf der Build-Seite steht dafür ein Posten, den Einsteiger chronisch unterschätzen: Wartung. Studien zur Software-Ökonomie beziffern den Wartungsanteil an den Lebenszykluskosten regelmäßig auf 60 bis 80 Prozent.
Rechne das einmal durch: Ein Projekt mit 200.000 Euro Entwicklungsbudget steht damit über seinen Lebenszyklus bei grob 500.000 bis 1.000.000 Euro Gesamtkosten. Die Differenz, also 300.000 bis 800.000 Euro, ist Wartung: Patches, Dependency-Updates, kleine Erweiterungen, Betrieb. Wer nur das Entwicklungsbudget bewilligt, hat die kleinste Zahl des Projekts bewilligt.
In einfachen Worten: Bei Buy zahlst du für fremde Software und pflegst die Nähte. Bei Build zahlst du für eigene Software und pflegst alles. Die ehrliche TCO-Rechnung stellt beide Pflegekosten nebeneinander, nicht Lizenz gegen Projektbudget. Eine Eigenentwicklung ohne festen Owner ist deshalb keine Investition, sondern ein zukünftiges Legacy-Projekt mit Ansage.
Wann bauen? Drei Bedingungen, die alle erfüllt sein müssen
Nach den drei Kostenposten bleibt die angekündigte Menschen-Frage, und mit ihr lässt sich die Build-Entscheidung präzise fassen. Baue selbst, wenn drei Bedingungen gleichzeitig gelten.
Erstens: Der Prozess differenziert dich. Das ist die strategische Achse aus dem Entscheidungsmatrix SaaS vs. Individualsoftware, und sie bleibt die Eintrittskarte. Für Buchhaltung, Ticketing oder Newsletter-Versand baut niemand ernsthaft selbst.
Zweitens: Die Domäne ist stabil genug, dass sich die Investition amortisiert. Ein Prozess, der sich alle sechs Monate grundlegend ändert, weil der Markt es diktiert, ist ein schlechter Kandidat für eine fünfjährige Eigenentwicklung. Ein Kernprozess, der seit zehn Jahren im Prinzip gleich läuft und nur nie sauber abgebildet wurde, ist ein exzellenter.
Drittens: Es gibt ein Team, das die Software besitzt. Nicht gebaut hat, besitzt. Mit Budget, Verantwortung und einem Namen im Org-Chart. Fehlt dieses Ownership, gewinnt Buy fast immer, selbst bei starker Differenzierung, denn verwaiste Individualsoftware ist die teuerste Software überhaupt.
Fehlt eine der drei Bedingungen, kaufe. Das ist keine Kapitulation, sondern Portfolio-Hygiene: Engineering-Kapazität ist die knappste Ressource im Haus, und sie gehört auf Code, den nur ihr schreiben könnt.
Build vs. Buy: Die Entscheidungsmatrix für Techniker
| Kriterium | Spricht für Buy (SaaS) | Spricht für Build |
|---|---|---|
| Integrationsfläche | Wenige Nähte, saubere API, Webhooks, Sandbox | Viele schlechte Nähte zu Kernsystemen, Batch/CSV-Altlasten |
| Datenhoheit & Exit | Vollständiger Export, offenes Format, kalkulierbarer Wechsel | Daten nur im Anbieter-Schema, Exit-Aufwand unbekannt |
| Roadmap-Abhängigkeit | Anbieter-Roadmap deckt Bedarf, Deprecations verkraftbar | Kritische Logik hängt an Features, die der Anbieter jederzeit kippen kann |
| Preisentwicklung | Planbare Kosten, geringe Renewal-Risiken | Usage-/Credit-Modelle oder AI-Bundles machen Kosten unkalkulierbar |
| Ownership | Kein Team, das langfristig besitzt | Benanntes Team mit Budget und Betriebsverantwortung |
| Differenzierung | Commodity-Prozess | Prozess ist Wettbewerbsvorteil |
Die Matrix ist bewusst unbequem: Sie zwingt dich, Exit-Aufwand und Ownership zu beziffern, bevor die erste Lizenz unterschrieben oder das erste Ticket geschnitten ist. Wenn zwei oder mehr Zeilen klar auf einer Seite stehen, ist die Entscheidung meist gefallen.
Der dritte Weg ist meistens der richtige
Die reine Binärfrage ist ohnehin eine Vereinfachung. Die robustesten Architekturen kombinieren: gekaufte Commodity-Dienste an den Rändern, eine schmale, selbst entwickelte Kernschicht dort, wo die Differenzierung liegt, und dazwischen bewusst gestaltete, dokumentierte Schnittstellen statt gewachsenem Glue-Code.
Dieser dritte Weg hat eine Spielart, die in klassischen Make-or-Buy-Rechnungen fehlt: Software selbst betreiben statt mieten. Open-Source- und Fair-Code-Tools wie Metabase, Plausible oder n8n liefern SaaS-Funktionalität ohne SaaS-Abo, auf eigener Infrastruktur mit Coolify betrieben sogar ohne Plattformkosten. Datenhoheit und Exit-Pfad sind dabei per Definition gelöst; bezahlt wird mit Betriebsverantwortung. Für Commodity-Tools mit sensiblen Daten ist das oft der beste Kompromiss aus beiden Welten.
Welcher Schnitt für welches System der richtige ist, ist eine Architekturfrage, keine Einkaufsfrage. Genau dort setzen wir mit Systemarchitektur und Design an: die Grenze zwischen Kaufen, Bauen und Betreiben so zu ziehen, dass sie in fünf Jahren noch trägt.
Fazit: Entscheide im Code-Review-Modus, nicht im Vertriebstermin
Zurück zum Anfang: Build vs. Buy wird im Konferenzraum entschieden und im Code bezahlt. Du änderst das, indem du die Entscheidung wie ein Code-Review behandelst. Lies die API-Dokumentation, bevor du das Pricing-PDF liest. Beziffere den Exit, bevor du den Einstieg feierst. Und benenne den Owner, bevor die erste Zeile geschrieben oder der erste Vertrag unterschrieben ist.
Wer diese Reihenfolge einhält, trifft die Entscheidung, die nach drei Jahren noch richtig aussieht. Alle anderen optimieren die Zahl, die im ersten Jahr am kleinsten wirkt, und genau die wird am teuersten.
