Make or buy: Was Verlage 2026 selbst bauen sollten – und was nicht

Infografik mit Waage zwischen Bauen und Kaufen – Make-or-buy-Entscheidung für Verlage

KI-Werkzeuge machen Eigenentwicklung so güns­tig wie nie, gleich­zei­tig rüsten Softwarehersteller ihre Produkte mit KI auf. Für Verlage und Medienagenturen stellt sich die Frage »Make or buy« damit neu. Wir zeigen, wo Eigenbau sinn­voll ist und wo Standardsoftware die bessere Wahl bleibt.

Mitte September hat Gartner seine Prognose für KI-Ausgaben aktua­li­siert: Weltweit sollen sie 2026 um 49,5 Prozent auf rund 2,7 Billionen US-Dollar stei­gen. Zwei Details der Meldung sind für die Make-or-buy-Debatte aufschluss­reich. Die kurz­fris­tige Wachstumserwartung für KI-Plattformen zur Anwendungsentwicklung hob Gartner von 28 auf 39 Prozent an. Zugleich nutzen Unternehmen laut Gartner vor allem die einfa­che­ren KI-Funktionen, die ihre bestehen­den Softwareanbieter in die Produkte einbauen. Selbst bauen und zukau­fen laufen also paral­lel.

Was Publisher heute selbst bauen

Wie das in Medienhäusern aussieht, hat Digiday im April beschrie­ben. Publisher erstel­len per Vibe Coding, also Software per Prompt statt per Programmierung, eigene Werkzeuge: Ein Entwickler baute den Prototyp einer Customer Data Platform, nach­dem die Einführung einer gekauf­ten Lösung lang­wie­rig gewe­sen war. Ein Ad-Ops-Team setzte Brand-Safety-Tools und Portale für die Anlieferung von Werbemitteln in weni­gen Wochen um. Im Vertrieb entste­hen Agenten für Angebote und Mediaplanung. Business Insider nutzt Vibe Coding dage­gen für Prototypen und inter­ak­tive Quizze, ersetzt damit aber keine Herstellerwerkzeuge.

Die neue Option verän­dert auch Verhandlungen. Ein Verlagsmanager drängt laut Digiday auf einjäh­rige statt der übli­chen drei­jäh­ri­gen Laufzeiten, um sich den Eigenbau offen­zu­hal­ten. Natalie Drucker von Thoughtworks berich­tet, dass Hersteller teils Preisnachlässe von mehr als 50 Prozent anbie­ten. Zugleich nennen die von Digiday zitier­ten Manager die Grenzen: den Abstand zwischen einem funk­tio­nie­ren­den Prototyp und einem System für Tausende Mitarbeiter, unge­klärte Einwilligungen bei der Wiederverwendung von Daten und den Aufwand für Code-Reviews. Drucker bringt einen weite­ren Punkt auf: »When you go with a vendor, at least you do have some liabi­lity«.

Ähnlich fällt eine Herstellerstudie des Low-Code-Anbieters Retool aus: Befragt wurden 817 Kunden und Nutzer der Plattform; 35 Prozent der Teams haben demnach mindes­tens ein SaaS-Werkzeug durch einen Eigenbau ersetzt. Repräsentativ ist das nicht, die Richtung aber deckt sich mit den Berichten aus der Branche.

Was bedeutet das konkret? Make or buy nach Systemrolle

Einen Rahmen liefert die Bitkom-Studie »Softwarewelt 2036« vom Juni 2026. Sie beruht auf quali­ta­ti­ven Interviews mit zwölf Entscheidern und ist ausdrück­lich nicht reprä­sen­ta­tiv. Die Befragten erwar­ten, dass pauschale Lizenz- und Stundenmodelle unter Druck gera­ten und vernetzte Plattformen gegen­über Einzelprodukten an Bedeutung gewin­nen. Ein Zitat aus dem Bericht: »Ein Tool, das nur eine Sache kann und sich nicht in eine Plattform inte­griert, hat 2036 keinen Markt mehr.« Nachvollziehbarkeit, Auditierbarkeit und euro­päi­sche Datenhaltung sieht Bitkom als mögli­ches Unterscheidungsmerkmal.

Für Verlage und Agenturen ergibt sich daraus eine Unterscheidung nach der Rolle eines Systems:

  • Kaufen und inte­grie­ren: Systeme, die Inhalte, Rechte und Daten verbind­lich führen, also Redaktionssystem, DAM, Planung sowie Abo- und Anzeigenverwaltung. Hier zählen Rechtemodell, Versionierung, Herstellersupport und Haftung. Auch eMarketer rät, solche »Systems of Record« beim Hersteller zu lassen.
  • Konfigurieren statt program­mie­ren: Workflows, Metadatenschemata und Freigaben lassen sich in Standardsystemen meist abbil­den, ohne eige­nen Code warten zu müssen.
  • Gezielt selbst bauen: Randfunktionen mit klarer Schnittstelle, etwa Dashboards, interne Rechner, Anlieferportale oder Spezialexporte. Gute Kandidaten verar­bei­ten keine sensi­blen Daten, haben einen begrenz­ten Nutzerkreis und lassen sich notfalls erset­zen.
  • Prototyp als Lastenheft: Ein schnell gebau­ter Prototyp schärft die Anforderungen an einen Hersteller, auch wenn er nie in den Betrieb geht.

Unsere Empfehlung

Entscheiden Sie Make or buy nicht pauschal, sondern pro Funktion. Diese Fragen helfen dabei:

  • Gesamtkosten statt Bauzeit: Rechnen Sie Updates, Support, Schulung und Betrieb über mehrere Jahre mit. Diese Leistungen über­nimmt bei gekauf­ter Software der Hersteller, beim Eigenbau Ihr Team.
  • Laufzeiten bewusst wählen: Kürzere Verträge schaf­fen Spielraum, kosten aber oft mehr, weil Hersteller lange Laufzeiten rabat­tie­ren. Ein realis­ti­scher Eigenbau-Plan ist dafür die bessere Verhandlungsgrundlage als eine vage Drohung.
  • Andocken über Schnittstellen: Eigenbauten grei­fen über doku­men­tierte APIs und Webhooks auf Redaktionssystem und DAM zu, nicht direkt auf deren Datenbanken. So blei­ben Updates der Standardsoftware möglich.
  • Verantwortung und Ausstieg: Für jeden Eigenbau muss fest­ste­hen, wer ihn verant­wor­tet und was passiert, wenn das Tool abge­löst werden muss.

So unter­stützt aaroon

Als WoodWing-Integrator setzen wir dafür auf ao.Services: Wiederkehrende Aufgaben rund um WoodWing Studio und WoodWing Assets laufen dort als sichere, über­wachte und geprüfte Prozesse. Kunden können bei uns auch eigene Prototypen einrei­chen, etwa ein per Vibe Coding entstan­de­nes Werkzeug; wir machen sie als Dienst prozess­reif und betrei­ben sie als sichere, über­wachte und geprüfte Prozesse, mit dem KI-Account des jewei­li­gen Kunden bei einem der gängi­gen Anbieter.

KI macht das Bauen von Software güns­ti­ger. Das Betreiben bleibt eine Aufgabe, die jemand dauer­haft über­neh­men muss.

Quellen

Wie können wir Sie unter­stüt­zen?

Kostenloses Erst-Gespräch

Lassen Sie uns gemein­sam prüfen, wo in Ihren Kommunikations‑, Marketing- oder Unternehmensprozessen konkrete Effizienzpotenziale liegen.

– Henning Bartens, Co-CEO


Strukturiert. Ehrlich. Informativ.

Nach oben scrollen