From prototype that works to system that scales.
Product Architect, embedded with your team. 3 to 9 months. Hands-on. Planned exit.
I'm Philipp. Fifteen years building production systems for Siemens, Deutsche Telekom, and Mercedes-Benz, and advising the people who own them. Most senior people you'll meet have done one or the other. The stretch where a prototype has to grow up needs both, in one person, in the codebase.
Design heritage from frog and Intuity Media Lab.
The moment companies call
An idea has proven it works. The pilot impressed the right people. Now production is the next stretch and it looks heavy. The team is fighting the codebase. Adding more headcount made things slower. The architecture that carried you to v1 will not carry you to 100 engineers and a real production load. The decision that has to be made next is not a technology decision. It is an architectural one, and it determines the next 12 to 18 months. That is the moment I work in.
How I work
Hands-on. In the codebase. From day one. The first week is a diagnostic. I read the code, sit with engineers, designers, product owners, and business leads, and come back with a clear view of what will fight you next. Then I write code with your team, design the architecture, and make the decisions that determine the next 12 to 18 months.
I work closely with CTOs, CPOs, and technical leads on the working mode that scales from 10 developers to 100. With designers on the design system: what to keep, what to adapt. With product on KPIs and priorities. My engineering emphasis is frontend, but I work fluently across backend and operations, because most architecture problems live at the seams between disciplines, not inside one.
I plan my exit 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 the scaling problem rarely lives 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 one of the technologies I work with. Today it shows up in most engagements. The judgment that decides where it belongs, and where it does not, is the same judgment that has applied to every other technology decision for 15 years.
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
- 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 engineering organisations: a v1 product, an AI prototype, or a legacy platform replacement that has to become a real system without breaking what already works. Usually 30 to 200 developers. Often regulated, always operational. Based in Germany, working internationally across the EU and the US.
Selected Work
If your prototype is working and the next stretch looks heavy, 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