From AI idea to usable product.
AI Product Engineer. Product Architecture & End-to-End Delivery.
I'm Philipp. I build AI-powered products and integrate them into existing software. Working with your team, I combine product definition, architecture, and hands-on development, with clear validation, operational boundaries, and a planned handover.
Fifteen years of production systems for Siemens, Deutsche Telekom, and Mercedes-Benz. Design heritage from frog and Intuity Media Lab.
Want to know where AI pays off in your company, even without developers of your own? AI workshops for leadership and departments
The moment companies call
You can see where AI could pay off: a process that eats hours every week, knowledge locked in documents, a pilot that impressed the right people. What is missing is the step to software people actually use. Someone has to decide what is worth building, fit it into the systems you already run, prove it works on real data, and know what it costs and who owns it after launch. The model is rarely the hard part. Everything around it is. That is the moment I work in.
How I work
Hands-on. In the codebase. From day one. I start with the business problem: I sit with the people who will use the product, read the existing code, and come back with a clear view of what is worth building and what is not. Then I design the architecture, build it with your team, and connect models, data, interfaces, and the systems you already run.
I work closely with CTOs, product owners, and technical leads on scope and priorities. With designers on the interface people will actually use. I build with coding agents where they speed the work up, and I stay responsible for every line that ships. My engineering emphasis is frontend and integration, but I work fluently across backend and operations, because AI products fail at the seams between disciplines, not inside one.
Every product ships with its operating boundaries: how quality is evaluated, what is monitored, what it costs to run, and who owns it after launch. I plan the handover from day zero. The test is simple: can the team continue at the same quality without me? If yes, the engagement worked. For specialised needs or continuity, I bring in senior technical peers from my professional network.
I went independent because the problems I am best at solving sit between disciplines, not inside them. The architecture decision is also a design-system decision. The build-system decision is also an organisational one. The decision about where AI belongs is also a workflow one. Inside one team you can see one face of that. From outside, embedded for three to nine months, I get to fix all of them.
This way of working was shaped by formative years at frog and Intuity Media Lab, where understanding the people, the workflows, and the business came before the technology decision, and refined through 15 years of enterprise delivery at Siemens, Deutsche Telekom, and Mercedes-Benz.
What this looks like in practice
I came in as a frontend trainer at Deutsche Telekom: HTML5, CSS3, Vue.js, git workflows for the first wave of about fifty developers building the new Magenta View CRM. Two weeks in, I started asking the Chief Architect questions about how the platform was going to hold together once every European market was building inside it.
The questions earned me a different role. I was elevated to one of two frontend architects. The training programme stayed, but it stopped being the way new developers got productive. We introduced a pattern library that became the foundation for the design system the UX team built on top. We introduced a finite state machine for state retrieval so teams could reason about behaviour without reading each other's code. We designed a framework-agnostic microfrontend architecture so any team could ship at any time without coordinating with others.
By the end, 200+ developers across European markets were working in parallel on a CRM serving thousands of call-centre agents. Feature velocity went up 30%. Oracle Siebel was retired. The patterns transitioned cleanly to Telekom's internal architecture team in 2023.
I went in to teach Vue. I came out responsible for the architectural governance of two hundred engineers.
Why this combination is rare
I work at the seams between product, design, engineering, and operations, because an AI product rarely succeeds or fails inside one of them. CTOs talk to me in architecture terms. Designers talk to me in system terms. Product talks to me in outcome terms. Operations talks to me in workflow and KPI terms. I keep all of those conversations aligned to one thing: a product that ships, scales, and stays maintainable when I am gone.
The value is rarely in any single decision. It is in the seam where three teams stop writing the same business logic three different ways. Where a 200-developer organisation switches from training new joiners to giving them a platform that explains itself. Where a prototype becomes infrastructure.
AI is the focus of my work today. The judgment that decides where it belongs, where it does not, and how it fits into what already exists is the same judgment I have applied to every technology decision for 15 years.
I run workshops for leadership teams and department heads, including in companies without developers of their own: where AI brings your company the most, and what kind of solution fits. For development teams, there are workshops on working with AI in their own code. Each one starts with a day of getting to know your business and your people, and is then designed around what I find. See the AI workshops
A small example of the same thinking
I run an AI-driven optimisation across a Wolf heating system, a PV inverter, a home battery, and a weather-forecast feed. 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. 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.
What this is, and what it is not
What it is
- Senior judgment, in the codebase, with a planned exit
- One person, embedded in your team for 3 to 9 months
- Architecture decisions backed by working code, not slides
- AI built into the software you already run, with evaluation, monitoring, and cost control
- Cross-discipline fluency: product, design, engineering, operations
What it is not
- A strategy deck for the supervisory board
- An interim or fractional CTO with full P&L responsibility
- Staff augmentation or another freelance frontend developer
- An AI consultant with a roadmap looking for a problem
Who this is for
Built for industrial-software and Mittelstand organisations: an AI idea, an AI prototype, or an existing product that needs AI built in, and that has to become usable software without breaking what already works. Usually 5 to 200 developers. Often regulated, always operational. Based in Germany, working internationally across the EU and the US.
No software team of your own? Then a workshop is the better place to start. It begins with your business and your people, not with code. See the AI workshops
Selected Work
If you have an AI idea that should become a product people use, get in touch.
First step is a 30-minute conversation. No cost, no pitch. Tell me what you are dealing with and I will tell you honestly whether I can help. If there is a fit, the usual entry point is an Architecture Triage: two days of code review, stakeholder interviews, and a written diagnosis of what will fight you next.
Tell me what's going on