WM 2014. 14 Freunde, ein Tipp-Wettbewerb, und kicker.de war uns zu unsexy. Kicktipp gab es, aber es war nicht das, was wir wollten. Also: Raspberry Pi bestellt, Telegram-Bot gebaut, das Ding lief wochenlang durch. Seitdem lautet meine Antwort auf "gibt es das nicht schon?" immer: Schon. Aber passt es wirklich?

Das Build-vs-Buy-Dilemma

Die Frage, ob es "so ein Tool nicht schon gibt", kommt immer. Bei Kunden, beim eigenen Stack, bei jedem kleinen Prozess, der nervt.

Meine Antwort ist meistens: Schon. Aber passt es wirklich? Oder ist es einfach nur... vorhanden?

Das ist der entscheidende Unterschied. Vorhanden und passend sind zwei verschiedene Dinge. Jedes Produkt im AppStore loest ein Problem — nur nicht zwingend Dein Problem. Nicht mit Deinen Daten, Deinen Mitarbeitern, Deiner Art zu arbeiten.

Stangenware funktioniert nach dem Prinzip des groessten gemeinsamen Nenners. Das Tool passt fuer moeglichst viele — also passt es fuer niemanden perfekt. Du nimmst Kompromisse, die der Hersteller fuer Dich getroffen hat. Manchmal ist das in Ordnung. Manchmal ist es der Grund, warum Du jeden Montag wieder in ein Tool schaust und seufzt.

Wer ernsthaft wissen will, welche Tools in einem Stack wirklich zaehlten — und welche nur Kosten produzierten — sollte mal ehrlich durchzaehlen. Was bei meinem eigenen Audit herauskam, habe ich in 47 Tools im Stack — drei waren wirklich wichtig aufgeschrieben.

Was die Tipp-Bot-Story lehrt

Zurueck zur WM 2014.

Ich hatte drei konkrete Anforderungen: Tipp-Nachrichten in einer Telegram-Gruppe erkennen, bestaetigen, und nach jedem Spiel eine Auswertung an alle schicken. Keine Datenbank, kein Web-Frontend, keine User-Accounts. Nur genau das.

Kicktipp konnte mehr. Viel mehr. Aber das "mehr" war nicht mein Problem. Mein Problem war kleiner, spezifischer, und genau deshalb loeste kein fertiges Tool es sauber.

Drei Erkenntnisse, die damals und heute gelten:

Passgenau heisst: nicht mehr Funktionen als noetig. Der Bot kannte genau eine Aufgabe. Er fragte nicht nach, er bot keine Alternativen an, er hatte kein Dashboard. Er machte eine Sache — und die wirklich gut.

Nicht weniger als gebraucht. Andersherum gilt das genauso. Ein Tool, das Deine Kernfunktion nur halb abdeckt, zwingt Dich zu Workarounds. Workarounds fressen Zeit und erzeugen Frustration. Wenn eine Eigenloesungen beides kann — passgenau und vollstaendig — ist sie ueberlegen.

Laeuft einfach. Der Raspberry Pi lief wochenlang durch. Keine Anmeldung, keine Updates, keine Interface-Entscheidungen. Automatisierung, die wirklich laeuft, braucht keine Aufmerksamkeit. Das ist der Kern von dem, was ich heute Fokus-Automatisierung nenne: Du automatisierst genau die Dinge, die dann wirklich selbst laufen — und nicht neue Verwaltungsarbeit erzeugen.

Wann "selbst bauen" wirklich Sinn macht

Eigenbau ist kein Selbstzweck. Es ist eine Antwort auf konkrete Umstaende. Vier Kriterien, an denen ich das messe:

1. Hochgradige Spezifitaet. Wenn Dein Prozess so spezifisch ist, dass kein Standardtool ihn ohne drei Workarounds abbildet, ist Eigenbau ernsthaft zu erwaeGen. Je einzigartiger Dein Kernprozess, desto teurer werden Kompromisse mit Stangenware.

2. Datenkontrolle als harte Anforderung. Bestimmte Daten duerfen Dein System nicht verlassen. Kunden-Rohdaten, Vertragsinhalte, interne Kalkulationen. Ein SaaS-Tool bedeutet immer, dass Daten auf fremden Servern laufen. Eigenbau bedeutet: Du weisst genau, wo alles liegt.

3. Wartung ist leistbar. Das ist der ehrlichste Selbsttest. Ein Eigenbau-Tool ist nur dann sinnvoll, wenn jemand in Deinem Team oder in Deinem Umfeld es warten kann. Ein Pi-Bot mit 200 Zeilen Python ist wartbar. Ein selbst gebautes ERP ist es meistens nicht.

4. ROI ist ehrlich kalkuliert. Entwicklungszeit kostet. Wartungszeit kostet. Wenn ein SaaS-Abo 50 Euro im Monat kostet und Dein Eigenbau 40 Stunden Entwicklungszeit gefressen hat, rechnest Du nach, wann sich das amortisiert. Meistens laenger als gedacht.

Wann Stangenware genug ist

Es waere unehrlich, nur fuer Eigenbau zu argumentieren. Stangenware ist die richtige Wahl, wenn:

Das Problem Standard ist. Buchhaltung, E-Mail, Projektmanagement in kleinen Teams — hier haben schlaue Leute viele Jahre Arbeit investiert. Dieses Wissen kostenlos mieten ist klueg, nicht faul.
Die Kategorie sich schnell entwickelt. Bei KI-Tools zum Beispiel macht Eigenbau selten Sinn, weil sich die Faehigkeiten monatlich aendern. Wer hier selbst baut, baut auf treibendem Sand.
Das Team das Tool nicht beherrschen will oder kann. Ein brillant gebautes Tool, das niemand bedient, ist schlechter als ein mittelpraechtig passendes, das jeder versteht.
Compliance-Anforderungen fertige Auditpfade verlangen. SOC2, ISO 27001, GDPR-Dokumentation — das selbst zu bauen kostet mehr als jede Enterprise-Lizenz.

Die Kurzformel: Standard-Probleme loest man mit Standard-Werkzeug. Sonderprobleme manchmal mit Eigenbau.

FAQ

Nicht zwingend — aber Du brauchst jemanden, der den Eigenbau warten kann. Das kann ein freier Entwickler sein, ein KI-Tool wie Claude mit klarem Kontext, oder ein interner Kollege. Die entscheidende Frage ist nicht "kann ich es bauen?" sondern "kann ich es in einem Jahr noch anpassen, wenn sich die Anforderungen aendern?". Wenn die Antwort Nein ist, kalkuliere Wartungskosten als Fremdleistung ein — oder waehle Stangenware.

Deutlich hoeher als geschaetzt. Die Entwicklungszeit ist sichtbar, Wartung ist es nicht. Rechne grob: 20-30% der initialen Entwicklungszeit pro Jahr fuer Wartung, Bugfixes, Anpassungen bei sich aendernden Abhaengigkeiten. Ein Tool mit 40 Stunden Bauzeit kostet 8-12 Stunden jaehrlich. Das ist vertretbar. Aber bei groesseren Eigenloesungen skaliert das schnell in unwirtschaftliche Bereiche. Wer beschissene Prozesse automatisiert, zahlt diesen Preis besonders teuer — mehr dazu in Beschissene Prozesse zu automatisieren ergibt beschissene automatisierte Prozesse.

Open-Source ist oft der kluge Kompromiss. Du bekommst Werkzeug, das andere gebaut und getestet haben, kannst es anpassen, und hast keine Vendor-Lock-in-Risiken. n8n zum Beispiel ist Open-Source und laeuft auf eigener Infrastruktur — genau das richtige fuer Prozesse, bei denen Datenkontrolle zaehlt. Der Haken: Open-Source-Wartung ist reale Arbeit. Updates, Security-Patches, Breaking Changes. Der Mittelweg ist ein guter — aber kein kostenloser.

Drei Minuten Test. Schreib auf, was Dein Tool in einem Satz koennen muss. Suche dann fuenf Minuten nach fertigen Loesungen. Wenn Du in diesen fuenf Minuten keine findest, die den einen Satz sauber abdecken — ohne drei Workarounds — ist Eigenbau ernsthaft zu erwaegen. Wenn Du zwei oder drei findest: nimm die guenstigste, die Deine Datenschutz-Anforderungen erfuellt. Den Fokus-Check-Ansatz, zuerst den echten Engpass zu verstehen bevor man baut, beschreibe ich in Was ist Fokus-Automatisierung?.

Dann ist die Frage, ob der Schmerz gross genug ist. Kleiner Schmerz: Workaround dokumentieren und akzeptieren. Grosser Schmerz: Entwickler beauftragen, ein schlankes Eigenbau-Tool zu bauen — mit klarem Scope, klaren Anforderungen, ohne Feature-Creep. Das ist oft guenstiger als man denkt, wenn der Scope wirklich minimal bleibt. Der Pi-Bot hatte 200 Zeilen Code. Das ist ein Nachmittag fuer jeden, der ein bisschen Python kann.

Gebaut statt gekauft. Das unterschreibe ich.

Nicht als Ideologie. Als Werkzeugentscheidung, die ich jedes Mal neu treffe. Manchmal ist das fertige Tool gut genug. Manchmal ist passgenau die einzige akzeptable Antwort.

Welches Tool nervt Dich gerade am meisten, obwohl Du es brauchst?