The Short Version

I'm a Senior AI Product Architect. I've spent 15 years as a platform architect and technical lead at Siemens, Deutsche Telekom, Mercedes-Benz, and others. Today, my focus is designing and delivering production-grade AI systems for enterprise teams: from use-case discovery and PoC shaping through the data pipeline, model selection, and governance, with EU AI Act requirements in mind. The decisions that determine whether your AI system ships to production and stays there, or lives in a staging environment waiting for a sign-off that never comes.

The work is suited to a specific type of engagement: enterprise AI products and internal AI systems that need to move from pilot to production under real operational and governance constraints, not demo conditions.

My work spans automotive, telecommunications, smart energy, manufacturing, and driver training. The common thread: large organisations with complex platforms that need to ship without breaking what already works.

I'm 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've Learned

Most architecture problems aren't technology problems. They're 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.

AI creates real leverage in enterprise contexts in roughly three places: automating judgment calls that were too expensive to make at volume, surfacing patterns across data that humans can't hold in working memory, and accelerating development cycles for teams that are disciplined about what they hand to a model and what they review themselves. It doesn't reliably create leverage where the answer needs to be explainable to a regulator, where the training data reflects a world that no longer exists, or where the team doesn't have the capacity to maintain what gets built. The judgment required is the same judgment required in any other architecture decision: knowing the difference between a problem this tool genuinely solves and a problem it makes look solved until it isn't.

The most valuable skill I bring isn't choosing between frameworks or designing a micro-frontend shell. It's 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 speak the same language as UX designers, product managers, and engineers. That's rare, and it matters. Most architecture problems live at the seams between these disciplines. Being fluent in all three means I can bridge gaps that others don't even see.

I've shipped enough wrong decisions to know the difference between a conviction and a guess. When I'm certain, I'll say so. When I'm not, I'll 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 for clients like Walter AG and Mercedes-Benz. Those three companies shaped my critical thinking, cross-discipline collaboration, and hands-on approach. That's where I learned that the real challenge isn't writing good code. It's making good code survive contact with ten teams and three continents.

I went independent because the problems I'm best at solving sit where UX meets product meets engineering. 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 isn't enough. You need someone who can work across all of them.

Currently taking on new engagements.

If you're dealing with an engineering problem that needs senior technical judgment, I'd like to hear about it.