Bau es selbst
Jahrzehntelang war Standardsoftware die vernünftige Entscheidung: fertig, erprobt, billiger als alles Eigene. Diese Rechnung hat sich umgedreht. Nicht weil Standardsoftware schlechter geworden wäre, sondern weil Eigenbau um Größenordnungen billiger geworden ist. Was übrig bleibt, sind die Kosten, die man beim Standard immer mitgekauft hat und bisher hinnehmen musste.
Der Grund, aus dem man Standard nahm, ist weggefallen
Die Entscheidung für ein fertiges System war nie eine Liebeserklärung. Sie war eine Kostenrechnung: Eigenbau bedeutete Entwicklerjahre, und Entwicklerjahre waren das Teuerste im Haus. Dagegen war jede Lizenz billig, und jedes kostenlose Framework unschlagbar.
Diese eine Größe hat sich verändert. Was früher ein Quartal war, ist heute ein Nachmittag. Damit fällt das Argument weg, das die gesamte Konstruktion getragen hat.
Übrig bleibt die andere Seite der Rechnung, die vorher niemanden interessierte, weil sie alternativlos war: die Anpassung an fremde Vorstellungen, das Warten auf fremde Zeitpläne, das Mitschleppen fremder Altlasten, und eine Angriffsfläche, die du dir nicht ausgesucht hast.
Diese Posten standen immer in der Bilanz. Sie waren nur nie das Problem, weil die Alternative teurer war. Jetzt ist sie es nicht mehr.
Du kaufst nicht ein Stück Software, du kaufst einen Stammbaum
Die 79 sind die wichtigste Zahl in dieser Reihe. Ein Team entscheidet sich für ein Paket und übernimmt damit die Entscheidungen von Dutzenden Leuten, die es nie getroffen hat, über Code, den es nie gelesen hat. Im September 2025 hat eine einzige übernommene Entwickler-Zugangsberechtigung genügt, um Schadcode in achtzehn Pakete zu bringen, die zusammen auf 2,6 Milliarden Downloads pro Woche kommen. Keines dieser Pakete war unseriös. Sie waren nur überall.
Nicht schlechter. Auffindbar.
Hier ist die Stelle, an der die meisten Texte zu diesem Thema falsch abbiegen. Sie behaupten, Eigenbau sei sicherer. Das ist nicht wahr. Dein selbst gebautes System hat mit hoher Wahrscheinlichkeit mehr Fehler als ein etabliertes Projekt, an dem tausend Leute jahrelang geprüft haben.
Der Unterschied liegt woanders, und er ist wichtiger als die Fehlerzahl: MonokulturDer Begriff kommt aus der Landwirtschaft. Ein Feld mit einer einzigen Sorte lässt sich effizient bewirtschaften, aber ein Schädling, der zu dieser Sorte passt, nimmt das ganze Feld. Vielfalt ist ineffizient und überlebt. macht Angriffe wiederverwendbar.
Ein eigenes System steht in keiner dieser Listen. Es ist nicht sicherer, es ist nicht durchsuchbar. Wer es angreifen will, muss es zuerst verstehen, und das ist Handarbeit an einem einzigen Ziel, statt einer Schleife über hunderttausend. Das verschiebt nicht die Qualität deines Codes, sondern die Ökonomie des Angriffs, und diese Ökonomie entscheidet, ob du überhaupt vorkommst.
Der zweite Teil davon ist die Sichtbarkeit selbst. Ein Standardsystem verrät von außen, was es ist. Pfade, Kopfzeilen, Dateinamen und Fehlerseiten sind Fingerabdrücke. Jeder, der auf deine Seite schaut, kennt deinen Bauplan, bevor er den ersten Versuch macht.
Wo Standard weiter gewinnt, und zwar deutlich
Eine These, die keine Grenze kennt, ist eine Ideologie. Also hier die Grenze, und sie folgt einer einzigen Frage: Findet an dieser Stelle Austausch mit der Außenwelt statt?
Wo etwas dein System verlässt oder betritt, ist der Standard nicht nur erlaubt, sondern zwingend. Ein eigenes Datumsformat, ein eigenes Bildformat oder ein eigenes Übertragungsprotokoll macht dich nicht unabhängig, es macht dich unerreichbar.
Der härteste Fall ist Verschlüsselung. Eigene Kryptografie zu schreiben ist ein bekannter, gut dokumentierter Weg, sich selbst zu schaden. Nicht weil Eigenbau grundsätzlich schlecht wäre, sondern weil hier die Fehler unsichtbar sind: ein kaputtes Verschlüsselungsverfahren funktioniert im Test einwandfrei und schützt trotzdem nichts. Das gilt genauso für Anmeldeverfahren, Zeitzonen, Zeichenkodierung und Zahlungsabwicklung.
Die Regel lautet also nicht „nimm nie etwas Fertiges". Sie lautet: an den Rändern Standard, im Kern eigenes.
Die Trennlinie verläuft nicht zwischen groß und klein, sondern zwischen Austausch und Kern.
| Bereich | Wahl | Begründung |
|---|---|---|
| Protokolle, Formate, Zeichensätze | Standard | Reine Austauschfläche. Eigenes bedeutet hier Isolation. |
| Verschlüsselung, Anmeldung, Zahlung | Standard | Fehler bleiben unsichtbar und sind nicht testbar. |
| Datenbank, Laufzeit, Webserver | Standard | Ausgereift, austauschbar, kein Unterscheidungsmerkmal. |
| Deine Abläufe und Regeln | Eigenes | Genau hier unterscheidest du dich. Ein Fremdsystem zwingt dich in seine Vorstellung davon. |
| Deine Oberflächen und Werkzeuge | Eigenes | Der Anpassungsaufwand an ein fertiges System übersteigt inzwischen den Bau. |
| Deine Daten und ihre Struktur | Eigenes | Fremde Schemata bestimmen sonst, welche Fragen du überhaupt stellen kannst. |
Das Übertragbare ist das Wissen, nicht das Bauteil
Der Ratschlag „bau es selbst" wird oft als „fang bei null an" missverstanden. Das Gegenteil ist gemeint.
Vierzig Jahre Softwarebau haben Erkenntnisse hervorgebracht, die stimmen: Zustand trennen, Fehler früh sichtbar machen, Schnittstellen schmal halten, nichts doppelt führen. Diese Prinzipien sind das Wertvolle. Sie kosten nichts, sie erzeugen keine Abhängigkeit, und sie veralten nicht.
Das Bauteil dagegen bringt die Prinzipien nicht mit. Es bringt die Auslegung der Prinzipien durch fremde Leute mit, dazu deren Kompromisse, deren Altlasten und deren Fahrplan.
Das ist auch der Grund, warum bestehende Systeme weiter wertvoll sind, nur anders als gedacht: als Vorlage, nicht als Fundament. Man liest, wie ein ausgereiftes Projekt ein Problem gelöst hat, versteht warum, und baut es dann so, wie es zum eigenen Fall passt. Der Bauplan ist der Ertrag, nicht das Gebäude.
Ein Standardsystem zu übernehmen ist ein Klonvorgang. Du bekommst eine exakte Kopie von etwas, das für einen anderen Zweck entstanden ist, und jede weitere Kopie ist identisch. Das ist effizient und es ist ein Stillstand: eine Kopie kann nichts, was das Original nicht schon konnte.
Selbst zu bauen heißt, dass dein System deine eigene Bauanweisung trägt. Jede Anpassung ist eine kleine Abweichung, und die meisten davon sind nichts wert. Aber manche sind es, und die bleiben.
Mutation ist der Motor der Evolution. Ein System, das nur kopiert, hat diesen Motor nicht. Es kann sich verbessern, indem es wartet, bis jemand anderes etwas verbessert. Mehr nicht.
Die Frage hat sich gedreht
Sie lautet nicht mehr „können wir uns Eigenbau leisten?", sondern „können wir uns leisten, dass fremde Entscheidungen unser Geschäft bestimmen?".
Nicht alles auf einmal
Der Weg ist nicht die große Ablösung. Er ist das Stück, das heute am meisten weh tut, dann das nächste.
Standard bleibt an den Rändern
Protokolle, Verschlüsselung, Datenbanken. Wer hier eigenes baut, hat den Punkt nicht verstanden.
Der Prüfstein
Frag bei jedem Bauteil: bestimmt es, wie dein Geschäft arbeitet? Wenn ja, gehört es dir. Wenn es nur Daten transportiert, nimm den Standard und sei froh.
- Sonatype, State of the Software Supply Chain 2026. Schadpakete 2025, kumulierte Menge, Anteil je Paketverzeichnis. sonatype.com
- Socket, CVE-Auswertung 2025. Gesamtvolumen der Schwachstellenmeldungen und Anteil des WordPress-Ökosystems. socket.dev
- Unit 42, Palo Alto Networks. Angriffsfläche des npm-Verzeichnisses, Kaskade vom September 2025. unit42.paloaltonetworks.com
Zahlen zu Schwachstellen und Ausnutzungszeiten beziehen sich auf 2025 und das erste Halbjahr 2026. Sie beschreiben Meldungen und beobachtete Vorfälle, nicht die Gesamtzahl vorhandener Lücken.
