The AI Product Engineer who takes an AI idea all the way to software people use.

The Short Version

I am an independent AI Product Engineer. I turn AI opportunities into usable software, combining product judgment with architecture and implementation. The engagements that suit me share a profile: there is an idea or a prototype that shows promise, and someone now has to decide what is worth building, fit it into existing systems, prove it works, and make sure it can be operated after launch. Most AI initiatives stall in exactly that gap. That gap is where I work.

My approach when I come on board is the same every time. Analyse what is already there. Understand the business goal and the end customer. Sit with the engineering team and read the codebase. Talk to designers about the design system, what to keep, what to adapt. Work with product owners and business leads on KPIs and priorities. Work closely with CTOs, CPOs, and technical leads on scope, priorities, and how the product will be run after launch. Then I write code, design architecture, and ship to production alongside the team.

My work spans automotive, telecommunications, smart energy, manufacturing, and AI-driven training. The common thread: large organisations with complex platforms that need to ship without breaking what already works. AI is the focus of my work today. My enterprise background is what makes it land: I know how the systems AI has to plug into are actually built and run.

I am based in Germany. I started my career at Hewlett-Packard and frog, both US-headquartered companies, and have collaborated with distributed teams across the US, Europe, and India throughout my career. I travel on-site when the work calls for it, whether that is in Europe, the US, or elsewhere.

What I Bring That Is Hard to Hire

Most senior engineers came up through one stack. Most senior consultants never shipped under production load. I came up through both. That is what is unusual about my work, and it is what is needed to take AI from a convincing demo to a product people rely on.

The other half of the advantage is range. I have shipped product across many industries and many disciplines, and I have learned how to translate between them. CTOs talk to me in architecture terms. Designers talk to me in system terms. Product talks to me in outcome terms. Operations and business leads talk to me in workflow and KPI terms. I keep all of those conversations aligned to the same goal: a product that ships, scales, and stays maintainable when I am gone.

Most architecture problems live at the seams between disciplines, not inside them. The decisions that affect user experience are also build-system decisions. The technical constraints that shape product strategy are also data and governance decisions. The module boundaries that determine team velocity are also organisational decisions. Fixing them from inside one team is rarely enough. You need someone who can move across all of them and stay credible in each.

Most architecture problems are also not technology problems. They are ownership problems. Unclear module boundaries, shared dependencies nobody wants to maintain, build systems that punish teams for deploying independently. Fix the ownership model and the architecture follows.

The skill that matters most is not choosing a model or a framework. It is walking into a platform with 200 active contributors, understanding where the friction is within a week, and making decisions that hold up six months later.

I build with coding agents every day, and I stay responsible for what ships: reviewed, tested, and understood by the team that keeps it.

I plan my exit from day zero. I have shipped enough wrong decisions to know the difference between a conviction and a guess. When I am certain, I will say so. When I am not, I will say that too.

How I Got Here

I started as an IT apprentice at Hewlett-Packard, then studied computer science at Hochschule Furtwangen. My first professional years were at frog (global design consultancy), Jung von Matt/Neckar (creative studio), and Intuity Media Lab (innovation studio), building platforms and native interactive prototypes (iOS, Android, Web) for clients like Walt Disney Parks, Crytek, Walter AG, and Mercedes-Benz. Those three companies shaped my critical thinking, cross-discipline collaboration, and hands-on approach. That is where I learned that the real challenge is not writing good code. It is making good code survive contact with ten teams and three continents.

I went independent because the problems I am best at solving sit where product meets design meets engineering meets operations. The architecture decisions that affect user experience. The technical constraints that shape product strategy. The build systems that determine team velocity. These problems cut across organisational boundaries. Fixing them from inside one team is not enough. You need someone who can work across all of them.

The Same Thinking, Applied at Home

A small example outside of client work: I run an AI-driven optimisation across my own home energy system. A Wolf heating unit, a PV inverter, a home battery, and a weather-forecast feed, tied together to balance self-generated power against the heating demand of the next 24 hours.

I built it because the heating technician knew everything about the heating and nothing about the PV. The PV technician knew the inverter and nothing about the heating. Each of them was excellent inside their own discipline. Neither of them was set up to think about the seam between the two, which is exactly where the optimisation lives.

The thinking that gets me hired professionally is the same thinking I apply to the house I live in. The value lives at the seams between systems, not inside any one of them.