Selbst bauen statt lizenzieren: Wann es trägt

Eine Firma ersetzt mit Coding-Agenten ein Produkt, für das sie 65.000 Dollar im Jahr gezahlt hat. So steht es in der Überschrift, und so wird der Fall seit dem Sommer weitergereicht. Im Beitrag selbst steht, was der Eigenbau gekostet hat: rund 109.500 Dollar.

Beide Zahlen stimmen, und zusammen beschreiben sie ziemlich genau, worum es in diesem Teil geht. Im Auftakt der Serie haben wir gezeigt, was ein kleines Team heute bauen kann. Hier geht es um die Käuferseite: Wann lohnt es sich für euer Team, ein Werkzeug selbst zu bauen, statt es zu lizenzieren?

Der Fall Fivetran, mit allen Zahlen

Fivetran, selbst ein SaaS-Anbieter, hat seine Statusseite bisher bei Atlassian gemietet. Teuer war sie vor allem, weil jeder der rund 26.000 Abonnenten der Benachrichtigungen einzeln abgerechnet wurde. Im eigenen Bericht beschreibt das Unternehmen, wie zwei Entwicklerinnen den Ersatz in etwa vier Monaten gebaut haben, mit sechs Agentenrollen, einer Projektdatei mit festen Regeln und echten Anforderungs- und Designdokumenten.

Die Zahlen sind Fivetrans eigene Schätzungen, gerechnet mit einem angenommenen Stundensatz von 100 Dollar:

Wie belastbar ist die Summe? Die Stunden stammen laut Fivetran aus Schätzungen an den Arbeitspaketen, nicht aus einer Zeiterfassung, und sind als Größenordnung gemeint. Luft ist in beide Richtungen. Zu hoch wäre die Summe, soweit die Entwicklerinnen anderes erledigen konnten, während die Agenten arbeiteten. Das ist bei dieser Arbeitsweise üblich, der Bericht sagt dazu aber nichts. Zu niedrig wäre sie, weil Management, QA und Design nach Fivetrans Angabe nicht mitgezählt sind. Klar ist nur der kleinste Posten: Die Tokens machen rund vier Prozent aus, und mit einem Abo statt Abrechnung nach Verbrauch dürfte es noch weniger sein.

Die erste lauffähige Fassung war schnell da. Mehr als die Hälfte der Arbeit steckt in dem, was danach kam: echte Anmeldung statt simulierter, eigene Datenbank, eigene Deploy-Pipeline, wochenlanger stiller Parallelbetrieb, Umstellung der Domain. Fivetran schreibt dazu: "Specification is the bottleneck, not code generation." Wer aus einer Demo nach zwei Wochen hochrechne, liege um den Faktor zwei oder mehr daneben.

Unterm Strich spart Fivetran nach eigener Rechnung 40.000 bis 53.000 Dollar im Jahr und hat die Baukosten nach rund zweieinhalb Jahren wieder drin. Rund 300 der Stunden verbucht das Unternehmen als einmaligen Aufwand für ein Agenten-Setup, das beim nächsten Projekt wieder zum Einsatz kommt. Der Bericht zieht auch selbst die Grenze: Wer statt 65.000 nur 10.000 Dollar im Jahr zahle, solle vermutlich weiter kaufen.

Die Gegenrechnung für 50 Leute

Genau in dieser Größenordnung liegen die Werkzeuge, über die gerade am meisten geredet wird. Im Doppelgänger Tech Talk #603 (ab 01:01) streiten die beiden Moderatoren über eine Hörerfrage dazu. Philipp Glöckler berichtet, er höre wieder häufiger von Firmen, die sich Notion oder Asana für den Eigengebrauch nachbauen, und rechnet sinngemäß mit ein paar hundert Euro Betrieb statt einer fünfstelligen Lizenz. Philipp Klöckner hält dagegen: Ein Werkzeug wie Monday.com lasse sich heute billiger bauen, als es seinen Hersteller einst gekostet hat, aber nicht billiger, als eine Lizenz kostet.

Die Listenpreise vom 11.10.2026 liegen dort, wo Klöckner sie verortet. Gerechnet für 50 Leute bei jährlicher Zahlung, ohne Steuern:

Monday nennt Listenpreise nur bis 40 Sitze, darüber gibt es ein Angebot vom Vertrieb. Die 50 sind also aus dem Preis pro Sitz hochgerechnet.

Jetzt legt Fivetrans Betriebszeile daneben. Ein Zehntel einer Stelle für die Pflege, dort mit rund 10.000 Dollar angesetzt, kostet etwa so viel wie eine dieser Lizenzen. Vom Bau ist da noch keine Rede. Zur Fairness gehört: Auch die gemietete Statusseite hat Fivetran nach eigener Angabe mindestens 10.000 Dollar interne Arbeitszeit im Jahr gekostet. Ganz ohne Betreuung läuft gekaufte Software ebenfalls nicht.

Klöckner nennt zwei weitere Posten, die in keiner Tabelle stehen. Wer nachbaut, hat den Stand von heute und zieht jedes künftige Feature selbst nach. Und die Leute, die das Werkzeug bauen und pflegen, fehlen am eigenen Produkt.

Einen Punkt aus Glöcklers Seite solltet ihr trotzdem mitnehmen. Wer nachbaut, merkt oft erst dabei, wie wenig vom gekauften Werkzeug genutzt wurde und dass längst nicht alle Lizenzinhaber es brauchen. Diese Erkenntnis gibt es auch ohne Eigenbau, ein Blick in die Nutzungsstatistik reicht.

Was an den bekannten Fällen dran ist

Wer nach Belegen sucht, findet zwei Sorten: große Namen, bei denen wenig dahintersteckt, und kleine Firmen mit erstaunlichen Zahlen, die sich schwer nachprüfen lassen.

Die letzte Zeile ist die interessanteste, weil sie Glöcklers Rechnung stützt und genau die Firmengröße trifft, um die es hier geht. Sie betrifft aber CRM-Verträge ab 40.000 Dollar, keine Aufgabenverwaltung für 6.000. Der Vertriebschef von Atonom sagt dazu: "No one was using Salesforce to its fullest potential." Eine teure Lizenz, von der nur ein schmaler Teil genutzt wird, ist ein anderer Fall als ein günstiges Werkzeug, das alle täglich offen haben.

Klarna wird gleich in zwei Richtungen falsch erzählt. Firmenchef Sebastian Siemiatkowski hat im März 2025 selbst klargestellt, wie TechCrunch zitiert: "we did not replace SaaS with an LLM". Klarna habe Daten aus vielen Systemen zusammengeführt und darauf eigene Oberflächen gebaut. In seinem Beitrag auf X schreibt er, es sei dabei um einheitliche Daten gegangen, weniger um Lizenzkosten. Laut CX Today ist das Unternehmen an anderer Stelle schlicht zu anderen SaaS-Anbietern gewechselt. Ob andere Firmen das nachmachen sollten, bezweifelt Siemiatkowski selbst. Was als Kehrtwende die Runde machte, betrifft etwas anderes: Laut heise stellt Klarna im Kundenservice wieder Menschen ein, zunächst in einem Pilotversuch, nachdem der Chef Qualitätseinbußen durch die KI-Strategie eingeräumt hatte. Mit Salesforce hat das nichts zu tun.

Für Kollaborationssoftware wie Monday, Asana oder Notion haben wir keinen dokumentierten Fall gefunden, in dem ein Unternehmen sie durch Eigenbau ersetzt hat, und aus dem deutschsprachigen Raum überhaupt keinen mit offener Rechnung. Das kann an der Suche liegen. Es passt aber zu den Preisen oben.

Was nach dem Bau bleibt

Unser Artikel über KI-Sicherheitsfunde beschreibt dasselbe Muster an anderer Stelle: Ein Schritt einer Kette wird billig, die übrigen bleiben teuer. Beim Eigenbau ist der billige Schritt das Schreiben von Code.

Wohin der Aufwand wandert, zeigt ein Feldbericht von OpenAI und akademischen Partnern über acht Forschungsprogramme, die mit Agenten neu geschrieben oder modernisiert wurden. Der Engpass bleibe "verification and validation", heißt es im Fazit, die Arbeit der Fachleute verschiebe sich vom Implementieren zum Spezifizieren und Prüfen. In einem der Projekte hatte der Agent einen Steuerparameter durch seinen Kehrwert ersetzt. Ein zweiter Fehler fiel laut The Decoder erst bei einem Abgleich mit tausenden synthetischen Datensätzen auf. Die Autoren betonen selbst, dass acht Projekte nicht repräsentativ sind.

Für ein internes Werkzeug heißt das: Die Fragen, die nach dem Start kommen, beantwortet kein Agent von allein.

• Wer spielt Sicherheitsupdates ein, wenn in einer Abhängigkeit eine Lücke bekannt wird?
• Wer wird angerufen, wenn das Werkzeug am Monatsende steht?
• Wer versteht es noch, wenn die Person geht, die es gebaut hat?
• Wer zieht die Daten um, wenn ihr es in drei Jahren doch ablösen wollt?

Fivetran beantwortet das mit einem Zehntel einer Stelle und hatte nach dem Start 29 offene Punkte auf der Liste. Unabhängige Zahlen dazu, was mit Agenten gebaute interne Werkzeuge über Jahre kosten, haben wir nicht gefunden. Die meisten dieser Werkzeuge sind erst wenige Monate alt.

Wenn die Fachabteilung selbst baut

Der Eigenbau entsteht oft gar nicht in der IT. In der Retool-Umfrage geben 60 Prozent der Befragten an, im vergangenen Jahr etwas außerhalb der IT-Aufsicht gebaut zu haben, ein Viertel häufig. Der meistgenannte Grund: Es geht schneller.

Was dabei herauskommen kann, hat der Sicherheitsanbieter RedAccess im Frühjahr gezählt. Laut Security Boulevard fand er rund 380.000 öffentlich erreichbare Anwendungen und andere Inhalte aus Baukästen wie Lovable oder Replit, etwa 5.000 davon mit sensiblen Firmendaten. RedAccess verkauft Schutz vor genau diesem Problem, und die Plattformen widersprechen der Deutung: Replit nennt öffentlich erreichbare Apps erwartetes Verhalten, Lovable und Base44 bemängeln, sie hätten keine Adressen zum Nachprüfen bekommen. Die Zahl ist also mit Vorsicht zu lesen.

Im Geltungsbereich der DSGVO, also auch in Deutschland und Österreich, kommen deren Pflichten dazu. Die Schweiz hat ein eigenes Datenschutzgesetz, das wir hier nicht behandeln. Sobald das selbst gebaute Werkzeug personenbezogene Daten verarbeitet, also Kunden, Bewerber oder die eigenen Kollegen, gelten dieselben Pflichten wie für gekaufte Software. Mit einem Unterschied: Beim Eigenbau nimmt euch kein Anbieter einen Teil davon ab.

Das ist eine Einordnung und keine Rechtsberatung. Praktisch bedeutet es: Wer in der Fachabteilung baut, holt IT und Datenschutz dazu, bevor echte Daten im Werkzeug landen.

Wo Eigenbau trägt

Das klingt bis hierher nach einem Plädoyer fürs Kaufen. An drei Stellen kippt die Rechnung zugunsten des Eigenbaus.

Wenn der Preis an etwas hängt, das ihr nicht braucht. Fivetran hat im Kern einen Mailverteiler ersetzt, der pro Abonnent abgerechnet wurde. Atonom hat ein CRM bezahlt, von dem niemand den vollen Umfang nutzte. Wo eine Lizenz nach Sitzen, Kontakten oder Abrufen wächst, ihr aber nur einen schmalen Ausschnitt der Funktionen braucht, lohnt das Nachrechnen.

Wenn es das Werkzeug gar nicht zu kaufen gibt. Billige Entwicklung führt vermutlich vor allem dazu, dass mehr Software entsteht. Der Auswertungsschritt, den drei Leute jeden Monat von Hand machen, oder die Fachanwendung für zwanzig Nutzer waren früher zu klein für ein Projekt. Auch Klöckner rechnet im Podcast mit mehr Werkzeugen für einzelne Branchen und mit Firmen, die mehr Budget in Tokens stecken als in Lizenzen.

Wenn es euer Kerngeschäft betrifft. Ein Werkzeug, das genau euren Ablauf abbildet, kann ein Vorteil sein, den kein Standardprodukt liefert. Dann gehört die Pflege zur Arbeit am Produkt.

flowchart TB
  A{"Anforderungen<br/>aufschreibbar?"}
  A -->|nein| K(["Nicht bauen"])
  A -->|ja| B{"In zwei Jahren<br/>jemand zuständig?"}
  B -->|nein| K
  B -->|ja| C{"Personen-<br/>daten?"}
  C -->|"ja: erst IT und<br/>Datenschutz"| E
  C -->|nein| E{"Kerngeschäft, teure Lizenz<br/>oder nichts zu kaufen?"}
  E -->|nein| K
  E -->|ja| F(["Bauen"])
  class A,B,C,E decision
  class F success
  class K abort
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC
  classDef abort fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5

Die Rechnung in kurz

Der Bau ist billig geworden, der Betrieb nicht. Wer das Monday-Abo für 50 Leute kündigt, um das Werkzeug nachzubauen, dürfte kaum etwas sparen und bindet Leute, die am eigenen Produkt fehlen. Mit einer teuren Lizenz für einen schmalen Zweck oder einem Problem, für das es nie ein Produkt gab, habt ihr dagegen heute Möglichkeiten, die vor zwei Jahren kein Budget bekommen hätten.

Für die Verhandlung mit dem Anbieter müsst ihr gar nichts bauen. Wer weiß, wie viele Sitze wirklich gebraucht werden und was der schmale Ausschnitt kosten würde, den das Team tatsächlich nutzt, sitzt besser am Tisch.

Die weiteren Teile der Serie findet ihr unter dem Schlagwort David gegen Goliath. Der Auftakt: David gegen Goliath: Wer braucht noch Konzerne?