That's me.
Developer, Consultant, Implementer.
I stand for collaboration that is calm, clear, and reliable — especially when the topics become complex. At the intersection of technology and organization, I develop solutions that are not only technically sound, but also proven in everyday use.
Why I do this
I became a developer because I cannot let go of the question of how things can be made better. Not better in theory – but noticeably better for the people who work with them every day. That question led me from code into organisations: to the processes nobody questions anymore, the interfaces nobody owns, and the solutions built without truly understanding the problem.
My strongest drive is in frontend and user experience. Not because it is the visible layer – but because it is the layer where technology meets people. An architecture can be as elegant as you like: if the interface fails, the entire system fails for the person using it. This awareness has grown in me over years – through projects where I saw how much potential is lost through poor interfaces, and how much trust is built when an application simply works.
Based on personal experiences with people in need of assistance, accessibility means to me: no one should fail at an application because someone did not think of them while building it. That is a commitment I bring to every project – regardless of whether a client asks for it.
My Background
I have worked in different environments: in medium-sized companies, in public administration, and in the financial and banking sector. Each of these environments has its own logic, its own language and its own constraints – I know all three and move between them without losing context.
In the financial sector I worked as a software architect on regulated systems: systems that require audit trails, communicate via regulated APIs, and must withstand external audit pressure. That experience shapes my approach regardless of industry: security, traceability and clean documentation are not extras for me – they are the starting point.
What distinguishes me as a freelancer from an agency: I bring frontend passion and architecture experience into the same person. Design decisions and technical decisions arise from the same mindset – no translation loss between teams, no compromises nobody actually wanted.
How I work – and what I do not do
No project ping-pong.
You have one contact who both advises and implements. What is developed in analysis flows directly into development – no briefing loss, no restart at the handover, no junior developer reading the concept for the first time three weeks later.
Plain language instead of consultant-speak.
I do not speak a language that simulates complexity to justify value. If something does not make sense, I say so – in the first meeting, not after three months of project runtime. If a simpler solution is sufficient, I recommend it. Even if that means the project gets smaller.
Delivering instead of presenting.
My goal is not a convincing closing report. My goal is a solution your team can use tomorrow – documented, handed over, explained. The proof is in the result, not in the slide deck.
Knowing what is feasible.
Because I develop myself, I know the difference between an idea and an implementable solution. I promise nothing I cannot deliver – and I deliver what I promise.
Discretion as standard.
References and project details are shared only with explicit consent. What is discussed between us stays between us.
Teamwork
As an external developer and consultant I frequently work into existing structures – into teams already running, into organisations with established processes, into projects that already have a history. That requires a certain attitude: listening before judging, building trust rather than assuming it, avoiding friction without giving up clarity.
I have been integrated into existing development teams, advised and supported internal teams, and handed over solutions so that teams can continue without me. The latter matters most to me: I do not build dependency. Documentation, knowledge transfer and onboarding are a fixed part of every project – not optional, not an afterthought.
I join existing teams without creating friction – and leave them able to carry on without me.
What I work with
Frontend
Frontend
Backend & APIs
AI & Automation
Process & BPM
Standards
Away from the screen
If you spend the whole day designing systems, you need a counterbalance that is the opposite: no rules, no architecture, no planning. For me, that is water. Whether on a board, in a kayak or simply in the lake – water sports clear my head in the way I need for good work.
What I have taken from it: conditions change fast, and those who wait for everything to be perfect never get moving. An attitude that serves me well at work too.
Frequently Asked Questions
Judge for yourself – in conversation.
No sales pitch, no standard presentation. I listen, ask questions, and tell you honestly whether and how I can help. In 30 minutes you will know where you stand.
Schedule a free consultation