Python Entwicklung — Entwickler, Arbeitsweise und Code-Übergabe

5+ Jahre pro Entwickler

Teil der Lieferung

1–3 Wochen

Womit wir täglich arbeiten

Tests von Anfang an

pytest für Geschäftslogik und Schnittstellen. Nicht 100 % Abdeckung um der Zahl willen, sondern Tests dort, wo Fehler teuer werden.

Reviews durch Zweite

Kein Merge ohne Review durch eine zweite Person. Das findet nicht nur Fehler, es verteilt auch das Wissen im Team.

Typannotationen

Vollständig typisierter Code mit mypy oder pyright in der CI. Das fängt eine ganze Fehlerklasse ab, bevor sie überhaupt läuft.

Automatisierte Pipeline

Linting, Formatierung, Tests und Typprüfung laufen bei jedem Push. Was rot ist, geht nicht live.

Migrationen mit Rückweg

Datenbankänderungen werden versioniert und sind rückrollbar. Ein Deployment darf niemals eine Einbahnstraße sein.

Dokumentation im Repo

Architekturentscheidungen, Setup und Betriebsanleitung liegen beim Code — nicht in einem Wiki, das nach sechs Monaten niemand mehr pflegt.

Wer entwickelt konkret — Senior oder Junior?

Bei uns schreibt niemand Code, der nicht mindestens fünf Jahre Python-Erfahrung hat. Wir arbeiten in kleinen Besetzungen und verkaufen keine Teams, in denen eine erfahrene Person das Angebot schreibt und danach Berufsanfänger die Arbeit machen. Das ist der Grund, warum unsere Stundensätze nicht die günstigsten sind — und warum die Gesamtkosten trotzdem oft niedriger ausfallen.

Wem gehört der Code am Ende?

Euch, vollständig und ohne Einschränkung. Ihr bekommt das Repository mit vollständiger Historie, die Deployment-Konfiguration, die Dokumentation und ein Runbook für den Betrieb. Wir bauen keine Abhängigkeiten ein, die einen Wechsel künstlich erschweren — weder technisch noch vertraglich.

Was kostet ein Python-Entwickler bei euch?

Wir arbeiten mit Tagessätzen im mittleren dreistelligen Bereich, abhängig von Umfang und Laufzeit. Bei längeren Engagements sinkt der Satz. Für klar abgegrenzte Vorhaben bieten wir auch Festpreise an, allerdings erst nach einer bezahlten Analysephase — Festpreise auf Basis einer unklaren Anforderung sind für beide Seiten schlecht.

Könnt ihr unser bestehendes Team verstärken?

Ja, das ist eines von drei Modellen, in denen wir arbeiten. Wir kommen dann in eure Prozesse: euer Repository, euer Ticketsystem, eure Code-Review-Regeln, eure Stand-ups. Das funktioniert gut, wenn euer Team die Architekturentscheidungen behalten will und punktuell Kapazität oder Spezialwissen braucht.

Übernehmt ihr auch fremden, gewachsenen Python-Code?

Regelmäßig. Wir beginnen mit einem Assessment: Testabdeckung, Abhängigkeiten, Datenmodell, Deployment-Situation. Daraus entsteht eine Einschätzung, was tatsächlich Arbeit braucht und was besser in Ruhe gelassen wird. Nicht jeder alte Code muss modernisiert werden — vieles läuft und soll einfach weiterlaufen.

Wie lange dauert die Einarbeitung in unser Projekt?

Bei einer dokumentierten Codebasis mit Tests sind wir nach etwa einer Woche produktiv. Ohne Tests und Dokumentation dauert es zwei bis drei. Wir rechnen diese Zeit transparent ab und nutzen sie, um die Lücken zu schließen, die wir dabei finden — davon habt ihr auch nach uns noch etwas.

Arbeitet ihr remote oder vor Ort?

Überwiegend remote, mit regelmäßigen Terminen vor Ort, wenn es das Projekt braucht. Wir sitzen in Berlin und sind für Kundschaft in Deutschland gut erreichbar. Die Zusammenarbeit läuft über euer oder unser Ticketsystem, wöchentliche Zwischenstände und offenen Zugriff auf das Repository — ihr seht jederzeit, was entsteht.

Was einen guten Python-Entwickler ausmacht

Die Sprache selbst ist schnell gelernt — das ist einer der Gründe für Pythons Verbreitung. Der Unterschied zwischen jemandem, der Python schreiben kann, und jemandem, der wartbare Systeme baut, liegt woanders: im Datenmodell, in der Fehlerbehandlung, in der Frage, was passiert, wenn ein externer Dienst nicht antwortet.

Wir achten bei Einstellungen deshalb weniger auf Framework-Kenntnisse als auf Erfahrung mit Systemen, die längere Zeit im Betrieb waren. Wer einmal eine Migration auf einer Tabelle mit vielen Millionen Zeilen gemacht hat, trifft danach andere Entscheidungen als jemand, der nur auf der grünen Wiese gearbeitet hat.

Warum Testabdeckung keine Zahl ist

Eine Abdeckungsquote von 90 Prozent sagt wenig darüber aus, ob die richtigen Dinge getestet werden. Man erreicht sie leicht, indem man Getter und Konfigurationsdateien mitzählt, während die eigentliche Geschäftslogik ungeprüft bleibt.

Wir testen deshalb nach Risiko: alles, was Geld bewegt, Daten verändert oder mit externen Systemen spricht, hat Tests. Reine Darstellungslogik oft nicht. Das Ergebnis ist eine niedrigere Quote und eine höhere Sicherheit — und es macht die Testsuite schnell genug, dass sie tatsächlich bei jedem Commit läuft.

Zusammenarbeit mit internen Teams

Wenn wir ein bestehendes Team verstärken, übernehmen wir dessen Regeln, nicht umgekehrt. Euer Branching-Modell, eure Review-Vorgaben, eure Definition of Done. Das klingt selbstverständlich, ist es in der Praxis aber nicht — viele Dienstleister bringen ihre Prozesse mit und erzeugen damit Reibung, die niemandem nützt.

Was wir mitbringen, ist Erfahrung aus anderen Kontexten. Wenn uns etwas auffällt, sagen wir es — aber als Vorschlag, nicht als Bedingung. Die Entscheidung bleibt bei dem Team, das danach damit weiterlebt.