Warum ich aufgehört habe, Freelancer für Datenprojekte zu buchen
Ich habe Datenprojekte mit Freelancern gemacht. Einige haben gut funktioniert. Einige haben eine bestimmte Art von Problem produziert, das ich am Anfang nicht richtig eingeordnet habe – und das sich erst nach dem Projekt gezeigt hat.
Das Problem heißt Handover. Oder genauer: das Fehlen eines funktionierenden Handovers.
Das Handover-Problem
Ein typischer Projektverlauf: Ich beauftrage einen Scraping-Freelancer. Er baut die Pipeline. Das Ergebnis funktioniert. Das Projekt wird abgeschlossen.
Dann, drei Monate später, ändert die Ziel-Webseite ihr Layout. Die Pipeline liefert keine Daten mehr.
Jetzt habe ich ein Problem, das ich selbst lösen muss. Oder ich beauftrage den Freelancer erneut – wenn er verfügbar ist. Wenn er noch als Freelancer tätig ist. Wenn er sich noch an das Projekt erinnert.
Das ist das erste Handover-Problem: Die Abhängigkeit bleibt, auch wenn das Projekt endet.
Der Context-Verlust
Das zweite Problem ist subtiler.
Ein erfahrener Freelancer bringt Domain-Wissen mit, das er im Projekt aufbaut. Er versteht, welche Quellen zuverlässig sind. Er kennt die Eigenheiten der Ziel-Webseite. Er hat Entscheidungen getroffen – warum dieses Element und nicht jenes, warum tägliches und nicht stündliches Scraping, warum diese und nicht eine andere Datenstruktur.
Dieses Wissen ist nicht im Code. Es ist im Kopf des Freelancers.
Wenn der Freelancer das Projekt beendet – und das tut er, weil sein Geschäftsmodell Projekt-zu-Projekt ist – ist das Wissen weg. Was bleibt, ist ein Codebase, dessen Entscheidungen niemand mehr rekonstruieren kann.
Das ist nicht Böswilligkeit. Es ist Strukturproblem.
Die Accountability-Lücke
Das dritte Problem: Accountability.
Wenn eine Pipeline, die ich selbst betreibe, falsche Daten produziert – merke ich es. Es ist mein Monitoring, mein Alert, meine Verantwortung.
Wenn eine Pipeline, die ein Freelancer gebaut hat, falsche Daten produziert – und ich kein Monitoring habe – merke ich es möglicherweise nicht. Und wenn ich es merke, ist die Frage: Wer behebt es? Der Freelancer hat das Projekt abgeschlossen. Die Gewährleistung ist abgelaufen. Ich stehe vor einem Codebase, den ich nicht vollständig verstehe.
Das ist die Accountability-Lücke: Zwischen dem Moment, wo das Problem entsteht, und dem Moment, wo es jemand behebt, gibt es niemanden, der strukturell verantwortlich ist.
Was ich stattdessen mache
Ich habe zwei Alternativen zu projektbasiertem Freelancing:
Für kleinere, stabile Anforderungen: Selbst bauen, mit Monitoring und Dokumentation von Anfang an. Das bedeutet mehr Aufwand beim Setup – aber ich bin der Eigentümer, ich kenne die Entscheidungen, ich kann es pflegen.
Für komplexere oder volatile Quellen: Managed Service mit laufendem SLA. Das ist teurer als ein Freelancer-Projekt auf den ersten Blick – aber ich zahle nicht nur für den Bau, sondern für die Verantwortlichkeit. Wenn es bricht, ist es das Problem des Dienstleisters. Das hat einen Preis. Und dieser Preis ist in vielen Fällen sinnvoll.
Was ich nicht mehr mache: Einmaliges Freelancer-Projekt für eine Infrastruktur, die ich danach selbst betreiben muss – ohne Monitoring, ohne Dokumentation, ohne laufende Verantwortlichkeit.
Wann Freelancer trotzdem Sinn machen
Ich sage nicht, dass Freelancer grundsätzlich falsch sind. Sie machen Sinn, wenn:
Das Projekt wirklich einmalig ist. Eine Datenanalyse, ein einmaliger Import, ein Report – keine laufende Infrastruktur. Kein Handover-Problem, weil es nichts zu übergeben gibt.
Der Freelancer ins Team übergeht. Wenn der Freelancer mit Abschluss des Projekts Mitarbeiter wird oder als langfristiger Vertragspartner mit laufendem Retainer weitermacht – dann ist das kein Freelancer mehr, sondern ein Dienstleister. Andere Kategorie.
Ihr die Pipeline danach selbst warten könnt. Wenn ein Data Engineer im Team ist, der die Pipeline nach Abschluss übernimmt und versteht – dann ist das Handover-Problem lösbar. Voraussetzung: Der Freelancer dokumentiert ordentlich, und der interne Engineer ist von Anfang an eingebunden.
Die eigentliche Frage
Die Frage, die ich inzwischen stelle, bevor ich ein Datenprojekt vergebe:
„Wer trägt die Verantwortung, wenn es in 12 Monaten bricht?“
Wenn die Antwort „ich“ ist – und ich die Kapazität habe, das zu tragen – gut. Dann bauen wir so, dass ich es tragen kann.
Wenn die Antwort „niemand“ ist – dann sollte das in die Entscheidung über die Struktur des Projekts einfließen. Nicht in die Entscheidung, ob man es macht. In die Entscheidung, wie.
Weitere Ressourcen
Wenn du einen externen Datenpipeline-Dienstleister suchst – mit laufendem SLA und definierter Verantwortlichkeit:
→ Web Scraping Dienstleister – brain-maze.de
Und der grundsätzliche Artikel zur Make-or-Buy-Entscheidung:
