The Product Architect companies call when the prototype has to become a system.

The Short Version

I am an independent Product Architect. I help companies move from a prototype that works to a system that scales. The engagements that suit me share a profile: an idea has proven itself, and the team, the codebase, and the organisation now need a different shape to grow. The architecture that got the company to a working v1 will rarely carry it to 100 developers and a real production load. 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 the working mode that scales from 10 developers to 100. 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 shows up in most engagements today, but it is one technology in the kit, not the headline.

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 at the inflection point between a prototype and a production system.

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 between frameworks or designing a micro-frontend shell. 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 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.