Die Build-Falle – Warum die Entscheidung für den Eigenbau richtig erscheint – und was sie tatsächlich kostet

Die Entscheidung, die sich richtig anfühlt

Es gibt einen Moment, den die meisten Medienorganisationen kennen. Die verfügbaren Tools passen nicht wirklich. Der Agentur-Stack ist eine Black Box. Die Daten liegen irgendwo, wo sie niemand vollständig kontrolliert. Und jemand im Raum sagt: Wir sollten das einfach selbst bauen.

Es ist ein nachvollziehbarer Impuls. Die Organisation kennt ihre eigenen Workflows besser als jeder Anbieter. Die Anforderungen sind spezifisch. Das Team ist kompetent. Und die eigene Infrastruktur zu besitzen fühlt sich nach genau dem richtigen Schritt an.

Also wird die Entscheidung getroffen. Ein Team wird zusammengestellt. Ein Zeitplan festgelegt. Und der Bau beginnt.

Der Prototyp ist nicht das Produkt

Die ersten Monate sind ermutigend. Ein Prototyp nimmt Form an. Grundfunktionen funktionieren. Das Team zeigt erste Ergebnisse.

Was in dieser Phase selten sichtbar ist: die Distanz zwischen einem funktionierenden Prototypen und etwas, das produktiv betrieben werden kann. Das sind keine graduellen Unterschiede. Ein Prototyp muss funktionieren. Produktionsinfrastruktur muss unter Last funktionieren — über Jahre, mit wechselnden Teams, mit Daten, die sich verändern, mit Anforderungen, die zu Beginn niemand absehen konnte. Fehlerbehandlung. Audit-Trails. Versionierung. Skalierung. Sicherheit. Compliance.

Das sind keine Features, die man später hinzufügt. Sie sind das Fundament, auf dem alles steht.

Was das Budget nicht erfasst

Die direkten Kosten eines Eigenbau-Projekts sind leicht zu sehen: Entwickler, Infrastruktur, Tooling. Was selten eingerechnet wird, ist alles andere.

Jede Stunde, die ein internes Team mit Infrastrukturwartung verbringt, ist eine Stunde, die nicht in Medienstrategie, Optimierung oder Kundenarbeit fließt. Dieser Trade-off summiert sich. Nach zwei Jahren stellt sich oft heraus, dass ein erheblicher Teil der technischen Kapazität der Organisation von einem System absorbiert wurde, das eigentlich Kapazitäten freisetzen sollte.

Dann ist da noch die Frage der Kontinuität. Bei fast jedem Eigenbau gibt es irgendwann eine Person, die das System wirklich versteht — die weiß, warum bestimmte Architekturentscheidungen getroffen wurden, die die undokumentierten Abhängigkeiten im Kopf trägt. Wenn diese Person geht — und irgendwann geht sie immer —, ist die Lücke, die sie hinterlässt, schwer zu beziffern und noch schwerer zu schließen.

Software, die nicht aktiv gepflegt wird, veraltet schnell. Jeder neue Kanal, jede neue Datenanforderung, jede Compliance-Änderung bedeutet Anpassungsarbeit. Was als schlankes internes Tool beginnt, wird zu einem Vollzeitprojekt — ohne dass sich jemand bewusst dafür entschieden hätte.

Die Anzeichen, dass die Kalkulation kippt

Die Symptome der Build-Falle zeigen sich meist lange, bevor jemand sie als solche benennt:

• Das ursprüngliche Team hat sich teilweise verändert — und das Systemwissen ist mitgegangen
• Neue Anforderungen — ein neuer Markt, ein neues Reporting-Bedürfnis — erfordern jeweils mehr Aufwand als sie sollten
• Dokumentation existiert, hat aber Lücken, für deren Schließung niemand Zeit findet
• KI-Tooling wurde evaluiert oder pilotiert, aber die Anbindung an den eigenen Stack ist selbst ein Projekt
• Die Frage, ob man neu bauen oder weiterwarten soll, taucht regelmäßig auf — und wird nie abschließend beantwortet

Einzeln betrachtet wirkt jedes dieser Symptome beherrschbar. Zusammen beschreiben sie dasselbe Muster: Die Infrastruktur ist zum Kostenfaktor geworden — nicht zur Fähigkeit.

KI macht die Kosten sichtbar

KI hat dieses Problem nicht geschaffen. Sie hat die Konsequenzen schwerer beherrschbar gemacht.

KI auf einer selbst gebauten, wartungsintensiven Infrastruktur zu deployen scheitert meistens nicht an der KI selbst, sondern an den Daten darunter. Inkonsistente Strukturen, fehlende Schemata, Datenpunkte, die sich nicht verbinden lassen. KI braucht saubere, strukturierte, verlässliche Inputs. Was ein Eigenbau über Jahre ansammelt, ist in der Regel das Gegenteil davon.

Die Organisationen, die KI im Medienbereich heute produktiv einsetzen, haben eines gemeinsam: Sie hatten ein solides Datenfundament, bevor sie begannen. Nicht danach. Davor.

Die Entscheidung, die niemand revidiert

Selbst zu bauen ist selten die falsche Entscheidung wegen mangelndem Ehrgeiz oder fehlender Kompetenz. Es wird zur falschen Entscheidung, wenn niemand innehält und fragt, ob die Infrastruktur das Kerngeschäft tatsächlich differenziert — oder ob sie einfach existieren muss.

Infrastruktur, die das Kerngeschäft nicht direkt differenziert, ist ein laufender Kostenfaktor. Sie wächst. Sie bindet Menschen, die etwas anderes tun könnten. Und einmal eingebettet, ist sie sehr schwer wieder loszuwerden.

Das Fundament zu bauen ist wichtig. Ob man es selbst bauen muss, ist eine ganz andere Frage.

Wo Mercury ansetzt

Mercury wird seit 2012 in echten Medienoperationsumgebungen entwickelt. Nicht im Labor — sondern mitten in realen, hochkomplexen Betrieben, lange bevor der Begriff „KI-fähige Infrastruktur" existierte. Das bedeutet: Das System wurde um die tatsächliche Reibung des Media-Geschäfts herum gebaut — Multi-Agentur-Koordination, Budgetkomplexität, Reporting-Lücken, der Bedarf an einem System, das jeden Technologiezyklus übersteht.

Das Ergebnis ist eine Media-Operations-Plattform, die als System of Record funktioniert — offen, agenturunabhängig, API-first. Sie konkurriert nicht mit den Tools, die eine Organisation bereits nutzt. Sie gibt ihnen soliden Boden unter den Füßen.

Selbst zu bauen machte Sinn, bevor dieser Boden existierte. Heute weniger.
Das Fundament steht. Die Frage ist, ob man weiter das eigene warten will.