About me

Hi, I'm Julian Giesen. Senior Software Engineer & Architect, focused on mobile.

Thinking about bringing an outside engineer onto your team, and want to know who you'd be working with? I've been building software professionally for seven years, most of it in mobile. On teams like yours, I make the architecture calls and build alongside your engineers.

Based in Dinslaken, Germany · remote or on site in Germany
Julian Giesen with arms crossed in front of a bookshelf

Teams I've worked with

  • RK Vision Homes
  • kunveno
  • The COI
  • Diatro
  • OYC
  • Meine Heimat by Skowo
Why mobile

Software you hold in your hand.

Early on, I could tell smartphones would become part of everyone's day. I loved building for a device people control with a fingertip. On a touchscreen, an app only works if it's simple.

Then real users tried one of my apps and wrote to tell me how much they liked it. That's when I knew this was what I wanted to do.

These days, I often build for people who don't sit at a desk. Construction crews use my apps to document job sites, and technicians use them on service calls. They work one-handed, under time pressure, sometimes with no signal. That's why usability comes first for me.

Article How I build apps that work offline
Julian Giesen testing an app on his phone, with code on the laptop next to him
Principles

How I work.

Julian Giesen working on a tablet, with app designs on a large screen behind him
  • My work lives on your board.

    I work in your repositoryRepositoryThe place where a project's entire source code lives together with its history, usually on GitHub or GitLab. Anyone with access sees every version and every change.More in the glossary →, pick up your ticketsTicketA single task with a description, an owner, and a status, tracked in a tool like Linear or Jira. Anyone can check a ticket to see where the work stands.More in the glossary →, and follow your team's sprintsSprintA fixed stretch of work, usually two weeks. The team commits to a goal and shows a result at the end. Then it plans what comes next.More in the glossary →. For architecture and testing, I use patterns that have held up across more than 20 projects.

  • Your team can build on my work.

    Your team approves every change in code reviewCode reviewA second pair of eyes before code is merged. Bugs show up early, and knowledge spreads across the team.More in the glossary → before mergingMergeBringing a change into the main branch, usually after its pull request passes review. After the merge, the change is part of the code the team builds the next release from.More in the glossary → it. I document decisions where your team will find them: in the ticket or the repo.

  • Decisions you can follow.

    For calls that shape your product for years, I lay out the options and explain which one I'd pick. You get a say, even if you're not in the code every day.

  • I flag risks before they get expensive.

    If a ticket leaves out something that will cause trouble later, I say so before your team builds it.

  • Someone to talk mobile with.

    Bring me your mobile questions before you promise your customers a feature. I'll tell you what I'd do in your shoes.

How this works on your team
Values

What I stand for.

  • Honest

    After our call, you get my take, even if we don't end up working together.

  • Built to last

    I keep the structure clean so each new feature in your app doesn't take longer than the last.

  • Reliable

    When I commit to something, you can put it on your roadmap.

Tools

Tools I use.

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

I mainly work with FlutterFlutterGoogle's framework for building iOS and Android apps and web UIs from one codebase. One team ships both platforms from the same code, and both stay in step.More in the glossary → and DartDartThe programming language behind Flutter. Built by Google, easy to read, and made for apps that run smoothly on phones.More in the glossary →. With Flutter, your team builds each feature once, from one codebase for iOS, Android, and the web. For platform-specific features, I go native with SwiftSwiftApple's language for iPhone, iPad, and Apple Watch apps. It comes in when an app is built natively or when a Flutter app needs something only iOS offers.More in the glossary → and KotlinKotlinThe language for native Android apps, also used on the server. It shows up for Android-specific features and for backend services.More in the glossary →. I build supporting backend services in Kotlin or Node.jsNode.jsJavaScript on the server. A good fit for lean services and APIs that feed an app with data.More in the glossary →.

I handle the DevOpsDevOpsEverything it takes to move an app from code to the stores. That covers the pipeline, code signing, store uploads, and the tools behind them. For apps, the point is that every version ships the same way.More in the glossary → side too. I set up GitGitThe tool for version control. Every change is traceable, several developers work in parallel, and any earlier state can be restored.More in the glossary → workflows and build CI/CD pipelinesCI/CD and pipelinesAn automated run that builds the app, tests it, and uploads it to the stores. Anyone on the team can start it.More in the glossary → with GitHub Actions, CodemagicCodemagicA CI/CD service made for Flutter apps. It builds iOS and Android versions in the cloud and uploads them to the stores. Nobody on the team has to keep a Mac around for iOS builds.More in the glossary →, and Docker. For every release, your team can trace how it got to the app stores.

I work with coding agentsCoding agentA tool like Claude Code or Codex that works on its own inside a repository. It reads the code, plans a change, writes it with tests and documentation, and runs the checks. A harness spells out what the agent may change and the conditions for a merge.More in the glossary → every day, inside a harnessHarnessWritten rules and checks that apply to everyone who writes code, human or model. They include coding conventions, tests that run before every merge, and limits on what an agent may change. The rules and checks live as files in the repository.More in the glossary →: written rules and checks that live in your repoRepositoryThe place where a project's entire source code lives together with its history, usually on GitHub or GitLab. Anyone with access sees every version and every change.More in the glossary →. I own the architecture. I sign off on everything an agent produces before your team reviews it.

Testimonials

What clients say.

“Julian developed a complex coaching app for COI with his extraordinary expertise that has far exceeded our expectations.”
Dirk Kröger Founder, COI
“Thanks to Julian, we were able to save immense time in implementation and many development costs.”
Niklas Knuf CTO, Digital Solvings GmbH
Call

Let's get to know each other.

Give me thirty minutes and walk me through what's coming up. I'll tell you whether I'm a fit for your team, and how we'd work together.

  • Video call, no prep needed
  • Reply within one business day

Send a message

A few sentences are enough. I'll reply by the next business day.

For example: what you want to build, where things are stuck, and when you need it by.

I only use your details to reply to your message. See the privacy policy (in German).