Über mich

Hi, ich bin Julian Giesen. Senior Software Engineer & Architect, Schwerpunkt Mobile.

Du überlegst, mich in Dein Team zu holen, und willst vorher wissen, wie ich arbeite? Seit sieben Jahren entwickle ich beruflich Software, den größten Teil davon im Mobile-Bereich. In Teams wie Deinem treffe ich die Architekturentscheidungen und baue mit.

Aus Dinslaken · remote oder vor Ort
Julian Giesen mit verschränkten Armen vor einem Regal

Vertrauen von Kunden wie

  • RK Vision Homes
  • kunveno
  • The COI
  • Diatro
  • OYC
  • Meine Heimat by Skowo
Warum Mobile

Software, die man in der Hand hält.

Mir war früh klar, dass das Smartphone für alle zum Alltag gehören wird. Mich hat gereizt, für ein Gerät zu entwickeln, das man mit dem Finger bedient. Eine App taugt nur, wenn die Bedienung einfach ist.

Dann haben die ersten Nutzer eine meiner Apps verwendet und mir geschrieben, wie gut sie ihnen gefällt. Da wusste ich: Das wird meine Arbeit.

Heute entwickle ich oft für Menschen, die nicht am Schreibtisch sitzen: Aufnahmen auf der Baustelle, Aufträge im Außendienst. Sie bedienen die App mit einer Hand und unter Zeitdruck, manchmal ohne Netz. Deshalb steht bei mir die Bedienbarkeit an erster Stelle.

Artikel Wie ich Apps baue, die auch ohne Netz funktionieren
Julian Giesen prüft eine App auf dem Handy, daneben Code auf dem Laptop
Grundsätze

Wie ich arbeite.

Julian Giesen arbeitet am Tablet, im Hintergrund App-Entwürfe auf einem großen Bildschirm
  • Meine Arbeit liegt auf Deinem Board.

    Ich arbeite in Deinem RepositoryRepositoryDer Ort, an dem der gesamte Quellcode eines Projekts mit seiner Geschichte liegt, meist bei GitHub oder GitLab. Wer Zugang hat, sieht jeden Stand und jede Änderung.Mehr im Glossar → und mit Deinen TicketsTicketEine einzelne Aufgabe mit Beschreibung, zuständiger Person und Status, etwa in Linear oder Jira. Am Ticket sieht das Team, wie weit die Arbeit ist.Mehr im Glossar →, im SprintSprintEin fester Arbeitszeitraum von meist zwei Wochen. Das Team setzt sich ein Ziel und zeigt am Ende ein Ergebnis vor. Danach plant es, was als Nächstes kommt.Mehr im Glossar → Deines Teams. Für Architektur und Tests setze ich Muster ein, die ich in mehr als 20 Projekten erprobt habe.

  • Dein Team kann meine Arbeit weiterführen.

    Jede Änderung prüft Dein Team im ReviewCode ReviewVier-Augen-Prinzip, bevor Code zusammengeführt wird. Fehler fallen früh auf, und das Wissen verteilt sich im Team.Mehr im Glossar →, bevor sie in die App kommt. Entscheidungen halte ich dort fest, wo Dein Team nachschaut: im Ticket oder im Repository.

  • Entscheidungen, die Du nachvollziehen kannst.

    Bei Fragen, die Dein Produkt lange prägen, stelle ich die Optionen vor und begründe, welche ich empfehle. Du entscheidest mit, auch wenn Du nicht täglich im Code arbeitest.

  • Risiken spreche ich an, bevor sie teuer werden.

    Fehlt im Ticket etwas, das später Ärger macht, sage ich es, bevor Dein Team es baut.

  • Du hast jemanden für Mobile-Fragen.

    Stell mir Deine Mobile-Frage, etwa bevor Du Deinen Kunden etwas zusagst. Ich sage Dir, was ich an Deiner Stelle tun würde.

Wie das im Team abläuft
Werte

Wofür ich stehe.

  • Ehrlich

    Nach unserem Gespräch bekommst Du meine Einschätzung, auch wenn kein Auftrag daraus wird.

  • Nachhaltig

    Damit neue Features in Deiner App nicht mit jedem Mal länger brauchen, achte ich heute auf eine saubere Struktur.

  • Verlässlich

    Was ich Dir zusage, kannst Du fest einplanen.

Werkzeuge

Mein Werkzeugkasten.

  • Flutter
  • Dart
  • Swift
  • Kotlin
  • Android
  • iOS
  • Firebase
  • Supabase
  • React
  • Node.js
  • Docker
  • Git
  • Codemagic
  • GitHub Actions

Ich arbeite vor allem mit FlutterFlutterEin Framework von Google, mit dem aus einer Codebasis Apps für iOS und Android und auch Weboberflächen entstehen. Das spart ein zweites Team und hält beide Plattformen auf demselben Stand.Mehr im Glossar → und DartDartDie Programmiersprache hinter Flutter. Von Google entwickelt, gut lesbar und darauf ausgelegt, dass Apps flüssig laufen.Mehr im Glossar →. Mit Flutter baut Dein Team jede Funktion nur einmal, aus einer Codebasis für iOS, Android und Web. Spezielle Gerätefunktionen entwickle ich nativ in SwiftSwiftApples Programmiersprache für Apps auf iPhone, iPad und Apple Watch. Sie kommt zum Einsatz, wenn eine App nativ entsteht oder eine Flutter-App Funktionen braucht, die nur iOS bietet.Mehr im Glossar → und KotlinKotlinDie Programmiersprache für native Android-Apps, auch auf dem Server einsetzbar. Sie kommt für Android-Funktionen und für Backend-Dienste zum Einsatz.Mehr im Glossar →. Angrenzende Dienste setze ich in Kotlin oder Node.jsnode.jsJavaScript auf dem Server. Gut geeignet für schlanke Dienste und Schnittstellen, die eine App mit Daten versorgen.Mehr im Glossar → um.

Auch den DevOpsDevOpsAlles, was eine App vom Code bis in die Stores bringt: Pipeline, Signierung, Store-Upload und die Werkzeuge dafür. Bei Apps geht es vor allem darum, dass jede Version auf demselben Weg ausgeliefert wird.Mehr im Glossar →-Teil übernehme ich. Mit GitGitDas Werkzeug zur Versionsverwaltung von Code. Jede Änderung ist nachvollziehbar, mehrere Entwickler arbeiten parallel, und jeder frühere Stand lässt sich wiederherstellen.Mehr im Glossar →, GitHub Actions, CodemagicCodemagicEin Dienst für CI/CD, der auf Flutter-Apps zugeschnitten ist. Er baut iOS- und Android-Versionen in der Cloud und lädt sie in die Stores. Niemand im Team muss dafür einen Mac bereithalten.Mehr im Glossar → und Docker baue ich PipelinesCI/CD und PipelineEin automatischer Ablauf, der die App baut, testet und in die Stores lädt. Jeder im Team kann ihn starten.Mehr im Glossar →, über die jede Version nachvollziehbar in die Stores kommt.

Ich arbeite jeden Tag mit Coding-AgentenCoding-AgentEin Werkzeug wie Claude Code oder Codex, das im Repository selbstständig arbeitet. Es liest den Code, plant eine Änderung, schreibt sie mit Tests und Dokumentation und führt die Prüfungen aus. Was es anfassen darf und was vor dem Merge gelten muss, steht im Harness.Mehr im Glossar →, in einem HarnessHarnessFeste Regeln und Prüfungen für jeden, der Code schreibt, Mensch oder Modell. Dazu gehören Konventionen, Tests vor jedem Merge und Grenzen für das, was ein Agent nicht anfassen darf. Regeln und Prüfungen liegen als Dateien im Repository.Mehr im Glossar →: feste Regeln und Prüfungen, die in Deinem RepositoryRepositoryDer Ort, an dem der gesamte Quellcode eines Projekts mit seiner Geschichte liegt, meist bei GitHub oder GitLab. Wer Zugang hat, sieht jeden Stand und jede Änderung.Mehr im Glossar → liegen. Die Architektur verantworte ich selbst, und jedes Ergebnis eines Agenten nehme ich ab, bevor es in Dein Review geht.

Kundenstimmen

Stimmen aus der Zusammenarbeit.

„Der Kontakt war sofort sehr sympathisch und trotzdem äußerst professionell … es war rundum perfekt. Offene Kommunikation, gute Tipps, schnelle Umsetzung, was will man als Kunde mehr.“
Mario Krumm Geschäftsführer, OYC App
„Mit Julian zusammenzuarbeiten war vom ersten Gespräch an auf einem Niveau, das man sich als Dienstleister wünscht. Er ist diszipliniert, strukturiert und bringt Ordnung in komplexe Themen … Auch in der Kommunikation war unsere Zusammenarbeit auf Augenhöhe. Offen, respektvoll und direkt. … Als Mensch ist Julian angenehm klar, ruhig und zuverlässig.“
Yvonne Aurich Marketinganalystin und Strategin
Gespräch

Lernen wir uns kennen.

Erzähl mir in dreißig Minuten, was bei Dir ansteht. Ich sage Dir, ob und wie ich in Dein Team passe.

  • Per Video, ohne Vorbereitung
  • Antwort spätestens am nächsten Werktag

Anfrage schreiben

Ein paar Sätze reichen. Ich antworte spätestens am nächsten Werktag.

Zum Beispiel: Was soll entstehen, wo hakt es und bis wann brauchst Du es?

Deine Angaben nutze ich nur, um Deine Anfrage zu beantworten. Mehr dazu in der Datenschutzerklärung.