Der Fall für Eigenbau, neu gerechnet

Für ein Jahrzehnt war die Frage Kaufen versus Bauen geklärt. Software wollte gekauft werden. Die Rechnung war einfach: Entwicklungszeit ist teuer, die Feature-Geschwindigkeit etablierter SaaS-Anbieter war hoch, Integrations-Ökosysteme kumulierten Wert. Selbst Organisationen, die sich das Bauen leisten konnten, entschieden sich routiniert für den Kauf.

Etwas hat sich verändert. Nicht so, dass das Argument obsolet wäre — aber so, dass es sich lohnt, es neu zu prüfen.

Was Agents an der Rechnung tatsächlich ändern

Die alten Bau-Kosten wurden dominiert von Entwicklungsstunden. Jeder Screen, jeder Workflow, jeder Integrationspunkt verlangte, dass jemand Code schrieb, Randfälle testete und die Oberfläche pflegte, während sich Anforderungen verschoben. Ein mittelgroßes maßgeschneidertes System verbrauchte Entwicklungszeit in derselben Größenordnung wie das ursprüngliche Bauen — dauerhaft.

Agents verschieben das. Nicht das Coden — das wird seit Jahren marginal beschleunigt. Was Agents ändern, ist die Zusammensetzung eines laufenden Systems. Ein bedeutender Teil dessen, was früher Code war, wird zu geführtem Verhalten. Ein Agent, der eingehende Kunden-E-Mails liest, die Anfrage extrahiert, ein Formular ausfüllt und an den richtigen Spezialisten weiterleitet, ersetzt substanzielle Entwicklungsarbeit: kein E-Mail-Parser zu pflegen, keine Regelmaschine zu aktualisieren, kein Integrations-Adapter, der mit einer Fremd-API synchron gehalten werden muss.

Die Bau-Kosten bleiben real, aber die Zusammensetzung verschiebt sich. Weniger Dateien. Weniger Zustand. Mehr Prompts. Andere Ökonomie.

Substrat-Wiederverwendung — hier lebt die Verzinsung

Die andere Veränderung ist leiser. Wenn Sie Ihr erstes agentisches System bauen, investieren Sie in Substrat: einen Kernel, der LLM-Routing handhabt, Evaluationsrahmen, Beobachtbarkeit, Audit-Disziplin, Kostenverfolgung. Dieses Substrat ist nicht wegwerfbar. Es verzinst sich über jedes folgende maßgeschneiderte System, das Sie bauen.

Hier neigen sich die Kaufen-vs-Bauen-Ökonomien am schnellsten. Das zweite maßgeschneiderte System zu bauen beginnt bei 40-60% des Aufwands des ersten, weil das Substrat schon da ist. Beim dritten oder vierten ist der Großteil der Entwicklungsarbeit Domänenlogik und Eval-Design.

Im kleinen Maßstab war das früher schwer erreichbar. Man baute ein maßgeschneidertes System für den ersten Kunden, und jeder folgende Kunde brauchte einen Neubau, weil kein Substrat zum Erben da war. Jetzt ist das Substrat real.

Das Narrow-Agent-Prinzip auf Produktentscheidungen angewandt

Enterprise-SaaS ist per Konstruktion breit. Ein Tool, das fünf Kundensegmente bedient, muss die Vereinigung aller ihrer Workflows unterstützen, was aufgeblähte Oberfläche für jeden einzelnen Kunden bedeutet.

Maßgeschneiderte Systeme können schmal sein. Sie bauen genau den Workflow, den der Bediener täglich ausführt, und nichts anderes. Das Ergebnis ist kleiner, schneller, wartbarer — und der Bediener zahlt keine kognitive Steuer für Funktionen, die er nie nutzen wird.

Für einen Betrieb mit zehn Mitarbeitern kumuliert sich die Reibung eines aufgeblähten Tools über jede tägliche Interaktion. Für einen Betrieb mit fünfzig Mitarbeitern wird daraus eine Schulungs-, Onboarding- und Rekrutierungssignal-Kostenstelle („wir nutzen dieses Tool, das jeder hasst").

Eigentum als erstrangige Kategorie

Der Fall für Eigenbau ist nicht nur ökonomisch. Er ist eine Anspruchsgrundlage an Ihrer eigenen Workflow-Logik. In einem Enterprise-SaaS-Deployment bestimmt die Roadmap des Anbieters, was Sie ausdrücken können und was nicht. Ihre Workflow-Logik sitzt in deren Plattform, ist ihren Upgrade-Zyklen ausgesetzt, ihren Preisänderungen, ihrer Übernahme durch einen größeren Anbieter mit anderen Prioritäten.

Eigenbau ist das Gegenteil. Ihre Workflow-Logik ist Ihre. Ihre Daten liegen dort, wo Sie es entscheiden. Ihre Integrationspunkte sind gewählt. Preisbindung pro Platz an Ihre Belegschaft entfällt. Erzwungene Migration, wenn der Anbieter beschließt, das Preisniveau abzukündigen, auf dem Sie sich befinden, entfällt.

Für eine operative Oberfläche — die Werkzeuge, die Ihr Team täglich nutzt — zählt dieses Eigentum mehr als für periphere Werkzeuge.

Was sich nicht geändert hat

Eigenbau bleibt der schwierigere Weg. Agents senken die Kosten, sie eliminieren sie nicht. Substrat-Wiederverwendung verzinst sich, aber erst nachdem Sie das Substrat gebaut haben. Eigentum ist real, aber genauso die operative Verantwortung, die damit einhergeht.

Der Kauf-Fall bleibt richtig für Werkzeuge, die am Rand Ihres Betriebs sitzen, wo generalisiertes SaaS ausreichende Abdeckung ohne kognitive Steuer bietet. Er bleibt auch richtig, wenn der tägliche Workflow Ihres Teams eng dem meinungsstarken Design eines bestimmten SaaS folgt und das Tool unterstützend statt einengend wirkt.

Neu rechnen

Der Punkt ist, dass sich die Rechnung geändert hat. Eigenbau ist nicht universell die richtige Antwort und wird es nie sein. Aber wenn Sie die Kaufen-vs-Bauen-Frage zuletzt vor drei Jahren evaluierten und Ihre Antwort war „immer kaufen, weil Entwicklungsstunden zu teuer sind", hat sich die Arithmetik unter dieser Schlussfolgerung materiell verschoben.

Wenn Ihr Betrieb auf einem Stack läuft, der monatlich substanzielles Geld kostet, tägliche Reibung erzeugt und Workflow-Entscheidungen einschränkt, die Sie lieber selbst treffen würden, lohnt sich die Rechnung erneut. Der Eigenbau-Weg ist nicht mehr das, was er einmal war.