Selbst bauen, weil nichts passt

"JIRA ist ein Werkzeug für alle und damit für niemanden ganz richtig. Wir nutzten vielleicht dreißig Prozent der Funktionen." Das schreibt die Agentur 4eck Media aus Waren an der Müritz über ihren Wechsel zu einem selbst gebauten Projektwerkzeug. Gebaut hat sie es nach eigener Angabe in vier Wochen neben dem Tagesgeschäft, mit Claude Code.

Im zweiten Teil der Serie ging es ums Geld: Wann rechnet sich Eigenbau gegen eine Lizenz? Das ist aber nur die halbe Geschichte. Viele Teams bauen selbst, weil das Produkt am Markt ihr Problem nicht ordentlich löst. Es kann zu viel, ist für alle gedacht und deshalb mühsam einzurichten und zu bedienen. Um diese zweite Motivation geht es hier, und um die Frage, woran ihr merkt, dass ihr euch nur etwas vormacht.

Zu allgemein, zu mächtig, zu umständlich

Das Problem ist alt. Als LinkedIn 2011 Kafka vorstellte, begründeten die Entwickler den Eigenbau im Paper zu Kafka nicht mit Lizenzkosten, sondern mit dem Zuschnitt der vorhandenen Messaging-Systeme: "First, there is a mismatch in features offered by enterprise systems." Die Systeme böten Zustellgarantien, die man für Logdaten nicht brauche, und weiter: "Those unneeded features tend to increase the complexity of both the API and the underlying implementation of those systems."

Das beschreibt ziemlich genau, was viele Teams heute mit Projekt-, Ticket- oder Doku-Werkzeugen erleben. Ein Standardprodukt muss tausend Firmen gleichzeitig gefallen. Es bekommt Felder, Workflows, Rollen und Integrationen, die irgendwer braucht. Für das eine Team mit dem einen Ablauf ist das meiste davon Ballast, und den Ballast muss jemand konfigurieren, pflegen und neuen Kolleginnen erklären. Thomas Landgraf, der Jira für seine eigene Arbeit durch Markdown-Dateien im Repository und einen langen Claude-Code-Prompt ersetzt hat, fasst das so: "Traditional issue trackers grow by accretion. Each new feature adds complexity: custom fields, workflows, permissions, integrations."

Bei 4eck Media kamen weitere Punkte dazu: Oberflächenanpassungen nur in engem Rahmen, unnötige Klicks beim Anlegen von Tickets, und der Wunsch nach den eigenen Daten auf den eigenen Servern. Der Satz, der das zusammenfasst: "Wir wollten ein Werkzeug, das uns dient, nicht eines, dem wir uns unterordnen."

Früher endete diese Klage meist mit einem Achselzucken. Ein eigenes Werkzeug war ein Projekt, und für ein Projekt fehlten Budget und Leute. Das hat sich verschoben.

Was Anthropic mit Scion gebaut hat

Das bisher größte Beispiel stammt von Anthropic. Im Engineering-Blog vom 13.10.2026 beschreibt das Unternehmen, warum es git für sein Monorepo durch ein eigenes System namens Scion ersetzt hat, dazu ein eigenes Review-Werkzeug namens Antique.

Die Zahlen, alle von Anthropic selbst:

Der Auslöser war kein Preisschild. Git ist für verteilte Arbeit gebaut: Jeder Klon ist ein vollständiges Repository und funktioniert auch offline. Bei Anthropic sind fast alle Clients Agenten und CI-Jobs, die ohnehin immer online sind. Die Eigenschaft, die git für menschliche Entwickler gut macht, war hier im Weg. Anthropic schreibt, man habe die üblichen Abhilfen durchprobiert, von Shallow Clones über Sparse Checkouts bis zu Hunderten interner Spiegel: "We've used all of them." Sie hätten Zeit gekauft, mehr nicht.

Wichtig ist, was Anthropic ausdrücklich nicht behauptet: "Scion is by no means a suitable replacement for git for general use." Das ergebe nur bei riesigen Monorepos Sinn, mit Zehntausenden Entwicklern oder Schwärmen von Agenten. Und eine öffentliche Version wird es nicht geben, aus einem Grund, der direkt zu diesem Artikel passt: "Our internal versions of these components are highly bespoke, so they would be difficult for other organizations to adopt, and we worry that attempting to build a public version that tries to please everyone wouldn't actually be very useful."

Ein Werkzeug, das allen gefallen soll, wäre für Anthropic selbst also schlechter. Das ist der Kern des Arguments, nur aus der Gegenrichtung.

Auf eure Arbeit übertragbar ist der Aufwand. Anthropic schreibt: "In the past, developing and deploying a source control system like this would have taken a company years of iterative migration, with many more engineers." Ganz ohne Haken lief es nicht. Die Entwickler hätten oft vor allem Claude bremsen müssen, etwa wenn es sich über eine Grundannahme des Systems hinwegsetzte oder eine interne Schnittstelle übertrieben absicherte. Und Anthropic hat ein Token-Budget, das kaum ein anderes Unternehmen hat. The Register und Simon Willison erinnert das zentralisierte Modell an Subversion.

Früher Jahre, heute Wochen

Eigene Versionskontrolle ist keine Erfindung von Anthropic, das Unternehmen nennt Google und Meta selbst als Vorbilder. Der Vergleich zeigt, was sich geändert hat:

Belege: CACM 2016 zu Piper, Meta 2014 und Meta 2022, die übrigen sind oben verlinkt oder folgen unten.

Die oberen drei Zeilen sind Konzerne mit großen Teams und Jahren Zeit. Die unteren drei haben Wochen oder Monate gebraucht, bei Anthropic mit sieben Leuten, bei 4eck Media neben dem Tagesgeschäft.

Drei Fälle von heute

Ramp hat einen eigenen Coding-Agenten gebaut, statt ein fertiges Produkt zu nehmen. Die Begründung im Builders-Blog: "Owning the tooling lets you build something significantly more powerful than an off-the-shelf tool will ever be." Der Agent ist an die Werkzeuge angebunden, mit denen Ramp im Alltag arbeitet, von Sentry und Datadog bis Buildkite und Slack. Und er muss nur eine Sache können: "After all, it only has to work on your code." Nach einigen Monaten kamen laut Ramp rund 30 Prozent der gemergten Pull Requests in den Frontend- und Backend-Repositories von diesem Agenten. Ein Kostenargument taucht im Beitrag nicht auf. Komplett neu gebaut hat Ramp dabei nicht, das Team setzt auf vorhandene Bausteine. Das ist der Normalfall und kein Makel.

4eck Media ist der Fall aus der Einleitung. Ehrlich dazugehören zwei Dinge: Die Agentur nennt auch Kosten und Datenhoheit als Gründe, und sie verkauft Planora inzwischen als Produkt. Die Darstellung ist also nicht ganz uneigennützig. Wie viel Pflege das Werkzeug seit dem Umstieg braucht, steht nicht im Beitrag. Die "dreißig Prozent" sind eine Schätzung aus dem Bauch, keine Messung.

Thomas Landgraf zeigt das andere Ende: Eine Person ersetzt Jira durch Markdown-Dateien im Repository, die Claude Code pflegt. Für einen Einzelnen ist das schlank. Landgraf räumt selbst ein, dass Jira bei Epics über mehrere Teams und Standorte seine Stärken hat. Rechte, parallele Bearbeitung und große Teams sind mit Dateien im Repository nicht gelöst. Der Fall zeigt, wie stark Passung von der Größe abhängt: Was für einen passt, passt für fünfzig noch lange nicht.

Was die Zahlen hergeben, und was nicht

Wer die These "Standardsoftware kann zu viel" belegen will, landet schnell bei großen Zahlen. Die meisten sind dünner, als sie klingen.

Der Feature Adoption Report von Pendo aus dem Jahr 2019 kommt auf 80 Prozent der Funktionen, die selten oder nie genutzt werden, und auf 12 Prozent der Funktionen, die 80 Prozent der täglichen Nutzung erzeugen. Die Basis sind 615 Pendo-Kunden über drei Monate. Pendo verkauft Werkzeuge zur Nutzungsanalyse, und gemessen wird aus Sicht der Anbieter. Ob Nutzer die ungenutzten Funktionen als Hindernis erleben, sagt die Zahl nicht.

Die oft zitierten 64 Prozent "selten oder nie genutzt" der Standish Group sollte man nicht mehr verwenden. Mike Cohn hat nachgefragt, worauf sie beruhen: "Yes, four applications. And, yes, all internal-use applications. No commercial products."

Etwas näher an unserer Frage ist der Build-vs-Buy-Report von Retool. Von 488 Befragten, die im letzten Jahr an der IT vorbei selbst gebaut haben, nennen 25 Prozent als Grund, dass vorhandene SaaS-Werkzeuge ihren Bedarf nicht abdecken. Nur Geschwindigkeit liegt mit 31 Prozent vorn. Auch hier gilt: Retool verkauft eine Plattform für diesen Eigenbau.

Unabhängige Studien dazu, dass Teams wegen Konfigurationsaufwand oder Funktionsüberladung selbst bauen, gibt es kaum. Die These stützt sich auf Erfahrungsberichte wie die oben. Das spricht nicht gegen sie, sollte euch aber vorsichtig machen, wenn jemand mit Prozentzahlen argumentiert.

Oder ist es doch Not invented here?

Die naheliegende Gegenfrage: Habt ihr gründlich genug gesucht, oder wolltet ihr einfach selbst bauen? Das Not-invented-here-Syndrom, also die Abneigung gegen alles, was nicht aus dem eigenen Haus kommt, ist real.

Die Forschung dazu ist allerdings weniger eindeutig, als es oft klingt. Die klassische Studie von Katz und Allen aus dem Jahr 1982 misst streng genommen, dass die Leistung von Forschungsteams nach Jahren in derselben Besetzung sinkt. Takahashi und Inamizu kritisieren, dass sie trotzdem als Beleg für die Ablehnung fremder Lösungen zitiert wird, und bemängeln auch die Statistik. Belastbarer ist eine Studie von Hannen und anderen aus dem Jahr 2019: Sie beschreibt das Syndrom als "a persistent decision-making error arising from an attitude-based bias against external knowledge" und findet in einer Befragung zu 565 Forschungsprojekten einen negativen Effekt auf den Projekterfolg. Untersucht wurde Wissenstransfer in Forschung und Entwicklung, nicht der Eigenbau von Software. Die Übertragung ist naheliegend, aber eine Analogie.

Ein validiertes Kriterium, das berechtigten Eigenbau von Not-invented-here trennt, gibt es nicht. Joel Spolsky hat 2001 eine Faustregel aufgestellt, die bis heute hält: "Pick your core business competencies and goals, and do those in house." Was zum Kern eures Geschäfts gehört, baut selbst. Den Rest kauft.

Aus den Fällen oben lassen sich ein paar Prüffragen ableiten. Sie sind unsere Auswertung, keine Studie:

flowchart TB
  A{"Lücke<br/>benennbar?"}
  A -->|nein| N(["Eher Not<br/>invented here"])
  A -->|ja| B{"Produkte<br/>ausprobiert?"}
  B -->|nein| N
  B -->|ja| C{"Reicht eine<br/>Schicht?"}
  C -->|ja| L(["Kaufen, eigene<br/>Schicht darauf"])
  C -->|nein| D{"Betrieb<br/>geklärt?"}
  D -->|nein| L
  D -->|ja| F(["Selbst<br/>bauen"])
  class A,B,C,D decision
  class F success
  class N 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 erste Frage ist die wichtigste. "Jira nervt" ist keine Lücke. "Wir brauchen beim Anlegen eines Tickets drei Felder, das Werkzeug zwingt uns durch zwölf, und das lässt sich nicht abschalten" ist eine. Wer die Lücke nicht benennen kann, hat meistens nicht gesucht, sondern sich entschieden.

Die dritte Frage wird oft übersprungen. Zwischen "kaufen" und "neu bauen" liegt eine breite Mitte: ein Standardprodukt mit einer eigenen, schmalen Schicht obendrauf. So arbeitet Spotify mit Honk, und so entstehen eigene Mods für Claude Code. Ramp hat mit vorhandenen Bausteinen auch nicht bei null angefangen.

Die vierte Frage kennt ihr aus Teil 2: Der Bau ist billig geworden, der Betrieb nicht. Das gilt für passgenaue Werkzeuge genauso wie für billigere.

Kurz gesagt

Eigenbau hat zwei Motive. Das eine ist der Preis, das andere ist die Passung: Das Produkt am Markt löst ein allgemeines Problem gut und euer spezielles schlecht. Lange war das zweite Motiv kaum etwas wert, weil sich ein eigenes Werkzeug für ein kleines Team nicht lohnte. Mit Coding-Agenten bauen sieben Leute in fünf Monaten eine Versionskontrolle und eine Agentur in vier Wochen ihr Projektwerkzeug.

Das macht nicht jeden Eigenbau richtig. Wer die Lücke nicht benennen kann, den Markt nicht geprüft hat oder keinen hat, der das Ding in zwei Jahren noch pflegt, sollte die Finger davon lassen. Wer aber genau weiß, was ihm fehlt, darf das heute ernster nehmen als früher.