Das bin ich.
Entwickler, Berater, Umsetzer.
Ich stehe für eine Zusammenarbeit, die ruhig, klar und zuverlässig ist – gerade dann, wenn die Themen komplex werden. An der Schnittstelle von Technologie und Organisation entwickle ich Lösungen, die nicht nur technisch sauber sind, sondern auch im praktischen Einsatz überzeugen.
Warum ich das mache
Ich bin Entwickler geworden, weil mich die Frage nicht loslässt, wie Dinge besser werden können. Nicht theoretisch besser – sondern spürbar besser für die Menschen, die täglich damit arbeiten. Diese Frage hat mich vom Code in die Organisation geführt: zu den Prozessen, die niemand mehr hinterfragt, den Schnittstellen, die niemand verantwortet, und den Lösungen, die gebaut wurden, ohne das Problem wirklich verstanden zu haben.
Meinen stärksten Antrieb finde ich im Frontend und in der User Experience. Nicht weil das die sichtbare Schicht ist – sondern weil es die Schicht ist, an der Technologie auf Menschen trifft. Eine Architektur kann noch so elegant sein: Wenn die Oberfläche scheitert, scheitert das ganze System für den Menschen, der es nutzt. Dieses Bewusstsein ist bei mir über Jahre gewachsen – durch Projekte, in denen ich gesehen habe, wie viel Potenzial an schlechten Interfaces verloren geht, und wie viel Vertrauen entsteht, wenn eine Anwendung einfach funktioniert.
Aufgrund persönlicher Erfahrungen mit hilfebedürftigen Menschen bedeutet Barrierefreiheit für mich: Niemand soll an einer Anwendung scheitern, weil jemand beim Bauen nicht an ihn gedacht hat. Das ist ein Anspruch, den ich in jedes Projekt mitbringe – unabhängig davon, ob ein Auftraggeber danach fragt.
Mein Hintergrund
Ich habe in unterschiedlichen Umfeldern gearbeitet: in mittelständischen Unternehmen, in der öffentlichen Verwaltung und im Finanz- und Bankenbereich. Jedes dieser Umfelder hat seine eigene Logik, seine eigene Sprache und seine eigenen Zwänge – ich kenne alle drei und wechsle zwischen ihnen, ohne den Kontext zu verlieren.
Im Finanzumfeld habe ich als Softwarearchitekt an regulierten Systemen gearbeitet: Systemen, die Audit-Trails erfordern, mit regulierten APIs kommunizieren und unter externem Prüfdruck standhalten müssen. Diese Erfahrung prägt meinen Ansatz unabhängig von der Branche: Sicherheit, Nachvollziehbarkeit und saubere Dokumentation sind bei mir kein Extra, sondern Ausgangspunkt.
Was mich als Freelancer von einer Agentur unterscheidet: Ich bringe Frontend-Leidenschaft und Architekturerfahrung in dieselbe Person. Das bedeutet, dass Designentscheidungen und technische Entscheidungen in derselben Denkweise entstehen – ohne Übersetzungsverlust zwischen Teams, ohne Kompromisse, die niemand wirklich wollte.
Wie ich arbeite – und was ich nicht tue
Kein Projekt-Ping-Pong.
Sie haben einen Ansprechpartner, der sowohl berät als auch umsetzt. Was in der Analyse erarbeitet wird, fließt direkt in die Entwicklung ein – kein Briefing-Verlust, kein Neustart an der Übergabe, kein Junior-Entwickler, der drei Wochen später das Konzept zum ersten Mal liest.
Klartext statt Beraterdeutsch.
Ich spreche keine Sprache, die Komplexität simuliert, um Mehrwert zu rechtfertigen. Wenn etwas nicht sinnvoll ist, sage ich das – im Erstgespräch, nicht nach drei Monaten Projektlaufzeit. Wenn eine einfachere Lösung ausreicht, empfehle ich sie. Auch wenn das bedeutet, dass das Projekt kleiner wird.
Liefern statt präsentieren.
Mein Ziel ist nicht ein überzeugender Abschlussbericht. Mein Ziel ist eine Lösung, die Ihr Team morgen nutzen kann – dokumentiert, übergeben, erklärt. Der Beweis liegt im Ergebnis, nicht in der Folie.
Einschätzen können, was machbar ist.
Weil ich selbst entwickle, kenne ich den Unterschied zwischen einer Idee und einer umsetzbaren Lösung. Ich verspreche nichts, was ich nicht liefern kann – und ich liefere, was ich verspreche.
Diskretion als Standard.
Referenzen und Projektdetails teile ich nur mit ausdrücklicher Zustimmung. Was zwischen uns besprochen wird, bleibt zwischen uns.
Teamarbeit
Als externer Entwickler und Berater arbeite ich häufig in bestehende Strukturen hinein – in Teams, die bereits laufen, in Organisationen mit gewachsenen Prozessen, in Projekte, die schon eine Geschichte haben. Das erfordert eine bestimmte Haltung: Zuhören vor Urteilen, Vertrauen aufbauen statt voraussetzen, Reibung vermeiden ohne Klarheit aufzugeben.
Ich wurde in bestehende Entwicklungsteams integriert, habe interne Teams beraten und begleitet und Lösungen so übergeben, dass Teams ohne mich weitermachen können. Das letzte ist mir besonders wichtig: Ich baue keine Abhängigkeit auf. Dokumentation, Wissenstransfer und Einarbeitung sind fester Bestandteil jedes Projekts – nicht optional, nicht nachgelagert.
Ich trete in bestehende Teams ein, ohne Reibung zu erzeugen – und verlasse sie so, dass sie ohne mich weitermachen können.
Womit ich arbeite
Frontend
Frontend
Backend & APIs
KI & Automation
Prozess & BPM
Standards
Abseits des Bildschirms
Wer den ganzen Tag Systeme entwirft, braucht einen Ausgleich, der das Gegenteil davon ist: keine Regeln, keine Architektur, keine Planung. Für mich ist das das Wasser. Ob auf dem Board, im Kajak, unter Wasser oder einfach am See – Wasser ist mein Element und Wassersport macht mir den Kopf frei, den ich für gute Arbeit brauche.
Was ich dabei mitgenommen habe: Bedingungen ändern sich schnell, und wer darauf wartet, dass alles perfekt ist, kommt nicht vom Fleck. Eine Haltung, die mir auch in der Arbeit nützlich ist.
Häufige Fragen
Überzeugen Sie sich selbst – im Gespräch.
Kein Verkaufsgespräch, kein Standardpitch. Ich höre zu, stelle Fragen und sage Ihnen offen, ob und wie ich helfen kann. In 30 Minuten wissen Sie, woran Sie sind.
Jetzt Erstgespräch vereinbaren