A senior engineer on your team. Focused on mobile.
Your team owns the product. I pick up features in your sprint: my own tickets, your code review, your repo. You decide how much I take on, one phase at a time.
Teams I've worked with
I bring more to your sprint than extra capacity.
Access to 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 → and boardBoardA shared view of a team's tickets, in a tool like Linear or Jira. It shows what's up next, what's in progress, and what's done.More in the glossary → is all I need to get started. You assign me work like anyone else on your team, and I follow your sprint cadence.
More about me-
My own tickets on your board.
I take on whole features, each in its own ticketTicketA 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 →. You track each one in the same sprintSprintA 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 → as your team. You don't need a separate status report.
-
Your reviewers have the final say.
My work goes through your team's 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 →. Every pull requestPull requestA proposal to merge a change into the main branch, review included. GitLab calls it a merge request.More in the glossary → includes tests where they matter and explains why I made the change. I address your review comments like anyone else on the team.
-
Architecture decisions, written down.
I design the architectureArchitectureHow the software is divided into parts. It decides whether the next feature is easy or expensive.More in the glossary → behind my features and take responsibility for it. I record each decision and the reasoning behind it in your repo. A year from now, your team can still look it up.
Read more -
A harness for your team.
I work 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 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 → like Claude Code and Codex follow. The agents write code, tests, and documentation. I sign off on everything they produce before it reaches your reviewers. If you need one, I'll set up a harness for your team, built around your code and workflow.
-
In your channels.
I work in your team's channels: SlackSlackTeam chat with channels by topic. Quick conversations instead of long email threads.More in the glossary →, Microsoft TeamsMicrosoft TeamsChat, video calls, and files from Microsoft in one app, common in companies on Microsoft 365.More in the glossary →, or DiscordDiscordOriginally built for gaming communities, now used by many developer teams as a chat with voice channels.More in the glossary →. I reply within one business day. I flag vacations early and plan them into the sprint with you.
Three ways to work together.
How much I take on depends on what's coming up. We pick the right setup on our first call and revisit it each phase.
Typical projects: vertical software with a field app and a web app, and existing apps that need new features.
-
Advisory
I review architecture, pull requests, and the tricky parts. Your team builds the features.
-
Embedded
I join your sprints and own features end to end. Embedded is the most common setup.
-
Full-time, for one phase
I work only on your goal, such as a feature your customers are waiting for. We agree up front on what comes next.
What your team keeps.
Along with the features, your team gets what it needs for future releases.
-
Promises kept
Your team stays focused on its priorities. I build the feature you promised your customers.
-
Releases that don't depend on one person
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: builds, tests, and App Store and Google Play uploads run in one pipelineCI/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 →. After that, anyone on your team can ship a release.
-
Code your team can build on
My tests and decision records stay 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 →. Your team can pick up where I left off.
-
Knowledge that stays with your team
I put what I learn about your project into code reviews and your team's docs. If you want, I'll train your team, for example on architecture or working with coding agents.
How we get started.
- 1
A call
Thirty minutes over video. You tell me what's coming up. I tell you if I can help, and how.
- 2
Starter phase
It's fixed-price, with a defined deliverable, such as the first release in your existing app. Along the way, I learn your architecture and release process. If you'd like, I'll write up my findings and recommendations.
- 3
In your sprint
After that, we go phase by phase in your sprint. Each phase is fixed-price or time and materials. You set scope and priorities. After each phase, you decide whether to continue.
An example: Schützenleben.
The team behind Schützenleben (then called Mein Schützenleben) brought me in to build out their Flutter app. I built features from Jira tickets and Figma designs, added role-based permissions, and introduced BLoC for state management. In a two-day workshop, I trained the team on BLoC and database query optimization. Since then, they've kept building the app on their own.
Read the case study
What clients say.
“I had the pleasure of working with Julian on developing a new iOS & watchOS app, and I can confidently say he's an exceptional developer with remarkable adaptability! … Within just a short period and after receiving some initial guidance and PR feedback, he quickly became self-sufficient, tackling both feature development and bug fixes independently with confidence and skill. … I wouldn't hesitate to work with Julian again and highly recommend him for any mobile development role!”
Ben Rudhart App Engineer iOS & watchOS “Julian actively contributed to software development to support me on short notice. … He always works professionally and is willing to go the extra mile …”
Simon Hoffacker User Experience Designer, Schützenleben What I work with.
I mostly work in Flutter and go native with Swift or Kotlin when needed. I also build the supporting backend services and the pipeline.
- Flutter
- Dart
- Swift
- Kotlin
- Android
- iOS
- Firebase
- Supabase
- React
- Node.js
- Docker
- Git
- Codemagic
- GitHub Actions
-
Flutter and Dart
One codebase for iOS, Android, and the web app.
-
Native Swift and Kotlin
Native integrations like camera, location, or NFC, and full native apps when the project calls for it.
-
UI
Screens that are easy to use, built from reusable components.
-
APIs and offline
REST integrations that handle errors and offline use, then sync when the connection returns.
Read more -
App security
I store data encrypted on the device. The app asks for permissions only when it needs them.
-
Backend and pipeline
Supporting services in Kotlin or Node.js, and pipelines with GitHub Actions or Codemagic.
Read more
Questions about working with your team.
What does it look like when you join my team?
I join your development team as a senior software engineer focused on mobile. I take my own 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 → on your boardBoardA shared view of a team's tickets, in a tool like Linear or Jira. It shows what's up next, what's in progress, and what's done.More in the glossary →, and your reviewers have the final say. The code lives 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 build across the app, web app, and pipeline, mostly in Flutter and in Swift or Kotlin when needed. I'm Julian Giesen, based in Dinslaken, Germany, and I work remotely or on site. Since 2020, I've been part of more than 20 project teams, mostly on existing apps.
What do you need from my team to get started?
I need access to your repo, board, and channels, a point of contact for product questions, and the next feature. That's all the prep it takes. I get up to speed while the project keeps moving.
Do you work remotely or on site?
I mostly work remotely, in your team's channels and meetings. I come on site in Germany when we agree it helps, for example for the kickoff or a workshop.
Do you only work with Flutter?
No. Flutter is my focus, and I also build native apps in Swift and Kotlin. Supporting backend services and release pipelines are part of the job too.
How is this different from hiring an agency?
You talk to the person responsible for the architecture and the code. No agency in the middle passes your questions along. I work inside your team's workflow.
What does it cost?
Every engagement starts with a fixed-price starter phase and a defined deliverable. After that, we go phase by phase, fixed-price or time and materials, depending on how clear the scope is. I'll give you a price after our first call.
What about time zones?
I'm based in Germany, on Central European Time. We agree up front on the hours that overlap with your team.
What don't you do?
I don't do standalone UI/UX or design-system work, backend-only projects, or 24/7 operations and on-call duty. I also don't take on dedicated manual QA or fintech projects. If you need that, I can bring in partners I trust, with your OK.
Let's talk about what you've promised your customers.
Take thirty minutes to walk me through your sprint and how your team works. I'll tell you if I can join, and how.
- Video call, no prep needed
- Reply within one business day