[{"data":1,"prerenderedAt":97},["ShallowReactive",2],{"content:blog:senior-vakanz-bleibt-offen":3,"content:blog":33},{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":12,"toc":16,"body":32},"senior-vakanz-bleibt-offen","Softwareentwicklung: Unternehmen mit offener Senior-Stelle haben drei Wege","Weitersuchen, Freelancer oder Werkvertrag mit einem eigenen Team – was jeder Weg kann und was nicht","2026-09-04","Senior-Stelle bleibt offen: drei Wege statt Warten","Die Senior-Stelle in der Softwareentwicklung bleibt offen, Reviews stauen sich: drei Wege für Unternehmen in der DACH-Region und die Frage, wann welcher passt.","Ein Entwicklungsteam mit einer Handvoll Leuten, eine unbesetzte Senior-Stelle, Pull Requests, die auf Reviews warten. Wir vergleichen drei Wege – weitersuchen, ein Freelancer für ein abgegrenztes Thema, ein Werkvertrag mit einem eigenen Team – und schreiben auf, wann welcher passt. Einer davon ist unser Geschäft; die anderen beiden sind oft trotzdem die richtige Antwort.",5,[13,14,15],"Arbeitsweise","Werkvertrag","Engineering-Management",[17,20,23,26,29],{"id":18,"text":19},"kosten","Softwareentwicklung: Unternehmen zahlen die offene Stelle doppelt",{"id":21,"text":22},"weg-1","Weg 1: weitersuchen – aber anders",{"id":24,"text":25},"weg-2","Weg 2: ein Freelancer für ein abgegrenztes Thema",{"id":27,"text":28},"weg-3","Weg 3: Werkvertrag mit einem eigenen Team",{"id":30,"text":31},"entscheidung","Softwareentwicklung – Unternehmen entscheiden nach der Aufgabe","\u003Cp>Softwareentwicklung – Unternehmen mit einem Team aus einer Handvoll Leuten spüren eine unbesetzte Senior-Stelle sofort: Pull Requests warten auf Reviews, Releases rutschen, die verbliebenen Seniors lesen nur noch Code. Dieser Beitrag vergleicht drei Wege aus dieser Lage. Einer davon ist unser Geschäft; wir schreiben trotzdem auf, wann die anderen beiden besser sind.\u003C\u002Fp>\n\n\u003Ch2 id=\"kosten\">Softwareentwicklung: Unternehmen zahlen die offene Stelle doppelt\u003C\u002Fh2>\n\u003Cp>Die Suche nach einem erfahrenen Entwickler zieht sich nach unserer Erfahrung über ein halbes Jahr, und teuer ist sie ohnehin. Was in keinem Budgetantrag steht, ist der zweite Posten: was die offene Stelle in der Zwischenzeit kostet. In kleinen Teams sind Seniors der Engpass für alles, was nicht liegen bleiben darf – Reviews, Architekturentscheidungen, Produktionsstörungen, das Gespräch mit dem Fachbereich.\u003C\u002Fp>\n\u003Cp>Fehlt einer, verlangsamt sich nicht ein Projekt, sondern die Durchlaufzeit jeder einzelnen Änderung. Die Symptome ähneln sich von Haus zu Haus: Pull Requests warten tagelang, Releases rutschen, weil niemand die Verantwortung für den Merge übernehmen will, und die verbliebenen Seniors schreiben keinen Code mehr, sondern lesen nur noch. Gleichzeitig steigt der Druck, den Nächstbesten einzustellen – und eine Fehlbesetzung auf einer Senior-Stelle kostet mehr als die Vakanz.\u003C\u002Fp>\n\u003Cp>Die offene Stelle ist deshalb ein Signal, das eine Entscheidung verlangt. Nicht „Suche abbrechen“, sondern: Wie wird geliefert, solange sie offen ist – und was, wenn sie es noch eine Weile bleibt?\u003C\u002Fp>\n\n\u003Ch2 id=\"weg-1\">Weg 1: weitersuchen – aber anders\u003C\u002Fh2>\n\u003Cp>Die erste Option ist die naheliegende: bei der Suche bleiben. Auf lange Sicht ist sie die beste, wenn sie gelingt. Ein festangestellter Senior baut Wissen auf, das im Haus bleibt, prägt die Kultur der Mannschaft und ist pro Arbeitsstunde günstiger als jede externe Alternative.\u003C\u002Fp>\n\u003Cp>Die Nachteile sind ebenso klar. Auf die Zusage folgt die Kündigungsfrist, danach die Einarbeitung. Wer weitersucht wie bisher, bekommt in der Regel dasselbe Ergebnis. Sinnvoll ist Weitersuchen dann, wenn sich etwas an der Stelle ändert: die Anforderungsliste, die aus zwei Rollen eine gemacht hat; das Gehalt, das für den lokalen Markt zu niedrig angesetzt war; die Remote-Frage, die den Bewerberkreis auf den S-Bahn-Radius begrenzt.\u003C\u002Fp>\n\u003Cp>Passt, wenn: der Bedarf dauerhaft ist, das Team einen Kulturträger braucht, kein Termin auf dem Spiel steht – und Sie bereit sind, die Ausschreibung zu verändern statt sie nur zu verlängern.\u003C\u002Fp>\n\n\u003Ch2 id=\"weg-2\">Weg 2: ein Freelancer für ein abgegrenztes Thema\u003C\u002Fh2>\n\u003Cp>Die zweite Option ist der schnelle Weg: eine Anfrage auf einer Plattform, kurz darauf ein Dutzend Profile, jemand, der bald anfangen kann. Für ein klar umrissenes Spezialthema – eine Migration, ein Performance-Problem, eine Technologie, die niemand im Haus kennt – ist das oft der richtige Weg.\u003C\u002Fp>\n\u003Cp>Die Grenzen zeigen sich, wenn ein Freelancer nicht ein Thema, sondern die Senior-Lücke schließen soll. Erstens streut die Qualität: Ein Profil sagt wenig darüber, wie jemand Code reviewt oder mit dem Fachbereich spricht; das prüft der CTO selbst, in Arbeitszeit, die er nicht hat. Zweitens geht das Wissen mit der Person: Endet der Vertrag, beginnt die Suche von vorn, und der Nachfolger startet bei null. Drittens bleibt die Steuerung bei Ihnen – ein Freelancer erwartet Tickets, Prioritäten und Entscheidungen, also genau die Arbeit, für die der fehlende Senior gebraucht wurde.\u003C\u002Fp>\n\u003Cp>Ein vierter Punkt ist juristischer Natur und in Deutschland kein Detail: Wer über lange Zeit fest eingebunden ist und seine Aufgaben vom Teamlead des Auftraggebers bekommt, wirft die Frage nach Scheinselbständigkeit auf. Das ist kein Argument gegen Freelancer, aber ein Grund, den Einsatz von Beginn an als abgegrenztes Thema mit eigenem Ergebnis zu definieren.\u003C\u002Fp>\n\u003Cp>Passt, wenn: es um ein eingegrenztes Thema mit absehbarem Ende geht, jemand im Haus die Arbeit fachlich prüfen kann und die Übergabe nach Vertragsende von Anfang an eingeplant ist.\u003C\u002Fp>\n\n\u003Ch2 id=\"weg-3\">Weg 3: Werkvertrag mit einem eigenen Team\u003C\u002Fh2>\n\u003Cp>Die dritte Option ist die, mit der wir arbeiten: Ein Softwarehaus übernimmt ein abgegrenztes Stück Arbeit – ein Modul, eine Anbindung, eine Automatisierung – als Werk mit Abnahmekriterien und liefert es mit eigenen Entwicklern im eigenen Prozess. Der Unterschied zum Freelancer liegt nicht in der Person, sondern in der Organisation dahinter; die Abgrenzung der Vertragsformen erklärt der Artikel \u003Ca href=\"\u002Flexikon\u002Fwerkvertrag\">Werkvertrag\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Was das gegenüber der Vakanz löst: Das Review passiert beim Anbieter, mit dessen Leuten und dessen Prüfungen, bevor etwas bei Ihnen ankommt – Ihre Seniors nehmen ein Ergebnis ab, statt jede Zeile zu lesen. Fällt ein Entwickler aus, übernimmt ein Kollege aus derselben Mannschaft, ohne dass die Arbeit stehen bleibt. Und das Wissen über das Modul liegt beim Anbieter als Organisation, nicht bei einer Person, die morgen weg sein kann. Bei uns kommt dazu, dass alle Entwickler dieselbe Grundlage nutzen und mit KI-Werkzeugen arbeiten, die wir für unsere eigene Arbeit gebaut haben – die Details stehen unter \u003Ca href=\"\u002Fleistungen\u002Fsoftwareentwicklung\">Softwareentwicklung für den Mittelstand\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Was der Weg nicht kann, gehört genauso deutlich auf den Tisch. Erstens braucht er eine beschreibbare Aufgabe: „Wir brauchen jemanden, der mit anpackt“ ist kein Werk. Besteht die Arbeit vor allem darin, täglich im Strom der Tickets mitzuschwimmen, ist ein Werkvertrag das falsche Instrument. Zweitens muss die Übergabe in Ihre Codebasis geplant sein; ein extern gebautes Modul, das niemand im Haus versteht, ist die nächste Abhängigkeit. Drittens steuert der Anbieter seine Leute selbst. Wer die tägliche Kontrolle über jede einzelne Person will, bekommt sie hier nicht – das ist die Kehrseite davon, dass die Verantwortung für das Ergebnis beim Anbieter liegt.\u003C\u002Fp>\n\n\u003Ch2 id=\"entscheidung\">Softwareentwicklung – Unternehmen entscheiden nach der Aufgabe\u003C\u002Fh2>\n\u003Cp>Die drei Wege schließen sich nicht aus; sie beantworten verschiedene Fragen.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Weitersuchen\u003C\u002Fstrong> beantwortet die Frage nach dem dauerhaften Kern der Mannschaft. Das sollte nie aufhören – aber es sollte nicht die einzige Antwort auf die nächsten Monate sein.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ein Freelancer\u003C\u002Fstrong> beantwortet die Frage nach einer Fähigkeit auf Zeit, die im Haus fehlt und deren Ergebnis jemand prüfen kann.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ein Werkvertrag\u003C\u002Fstrong> beantwortet die Frage, wie ein abgegrenztes Vorhaben fertig wird, ohne die verbliebenen Seniors weiter zu belasten.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Die häufigste sinnvolle Kombination, die wir sehen: Die Ausschreibung wird überarbeitet und läuft weiter; parallel geht ein klar geschnittenes Vorhaben – oft die Anbindung oder Automatisierung, die lange im Backlog liegt – als Werk nach außen. Der neue Senior übernimmt später ein fertiges, dokumentiertes Modul statt einer halbfertigen Baustelle.\u003C\u002Fp>\n\u003Cp>Ob sich Ihr Vorhaben so schneiden lässt, klärt meist ein Gespräch über die Leistungsbeschreibung. Wenn die Antwort „nein“ lautet, sagen wir das – und empfehlen einen der beiden anderen Wege.\u003C\u002Fp>",[34,42,71],{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":35,"toc":36},[13,14,15],[37,38,39,40,41],{"id":18,"text":19},{"id":21,"text":22},{"id":24,"text":25},{"id":27,"text":28},{"id":30,"text":31},{"slug":43,"title":44,"subtitle":45,"date":46,"metaTitle":47,"metaDescription":48,"excerpt":49,"readingMinutes":11,"tags":50,"toc":55},"fuenf-jahre-bestellhistorie-ins-crm","Datenmigration ins CRM: fünf Jahre Bestellhistorie, keine Dublette","Wie wir einen Import so bauen, dass man ihn zweimal laufen lassen kann – und warum ein Archiv-Flag der wichtigste Teil war","2026-09-01","Datenmigration ins CRM: ohne eine einzige Dublette","Migration einer Shop-Historie in ein CRM auf PostgreSQL: idempotenter Import, Abgleich über E-Mail und Telefon, Archiv-Flag gegen Mailings an Altkunden.","Im CRM eines Lebensmittelherstellers mit Onlineshop standen 3 814 Bestellungen, im Shop lagen fünf Jahre Historie. Wir beschreiben, wie der Import idempotent wurde, wie Kontakte über E-Mail und Telefon zusammengeführt wurden und warum ein einfaches Archiv-Flag verhindert hat, dass die Automatik Altkunden anschreibt.",[51,52,53,54],"Migration","CRM","PostgreSQL","Praxisbericht",[56,59,62,65,68],{"id":57,"text":58},"ausgangslage","Die Lücke: 3 814 von 19 686",{"id":60,"text":61},"risiken","Drei Dinge, die bei einer Datenmigration ins CRM brechen",{"id":63,"text":64},"idempotenz","Derselbe Importer, derselbe Schlüssel",{"id":66,"text":67},"archiv","Dubletten und das Archiv-Flag",{"id":69,"text":70},"ergebnis","Was eine Datenmigration ins CRM am Ende beweisen muss",{"slug":72,"title":73,"subtitle":74,"date":75,"metaTitle":76,"metaDescription":77,"excerpt":78,"readingMinutes":11,"tags":79,"toc":82},"ein-stack-vierzig-services","Ein Software-Stack für vierzig Services: warum wir dabei bleiben","Was ein fester Stack dem Auftraggeber bringt, was er uns kostet – und wo wir davon abweichen","2026-08-25","Ein Software-Stack für vierzig Services","Ein Software-Stack für über vierzig Services: TypeScript, Node.js, PostgreSQL. Was Auftraggeber in der DACH-Region von dieser Entscheidung haben.","Über vierzig Services laufen bei uns auf derselben Kombination aus TypeScript, Nuxt 4, Node.js und PostgreSQL mit pgvector. Wir schreiben auf, warum ein Entwickler dadurch am ersten Tag in einem fremden Projekt arbeiten kann, was ein Auftraggeber konkret davon hat – und in welchen drei Fällen wir selbst zu einer anderen Grundlage raten.",[80,81,53,13],"Architektur","TypeScript",[83,85,88,91,94],{"id":30,"text":84},"Ein Software-Stack für alles: die Entscheidung dahinter",{"id":86,"text":87},"einarbeitung","Was Einarbeitung an einem Tag konkret heißt",{"id":89,"text":90},"auftraggeber","Was Auftraggeber von einem einheitlichen Software-Stack haben",{"id":92,"text":93},"postgres","Warum PostgreSQL für fast alles reicht",{"id":95,"text":96},"grenzen","Wo eine andere Grundlage die bessere Antwort ist",1789404874643]