status: building trustworthy systems
I build the infrastructure companies trust to run AI.
AI product engineering and infrastructure-as-code, for organizations that need real governance — not a demo.
before code, systems.
before i wrote a line of code, i studied how institutions work — universities, companies, the informal rules that hold an organization together when nobody’s watching. that turned out to be the right training for what i do now.
for almost ten years i’ve built software professionally. the shape of that work has changed more than once — and every shift taught me something the last one couldn’t.
these days the hardest part of any real ai adoption was never the model. it’s the governance around it — who’s allowed to use it, what data it can see, what happens when it’s wrong. that’s a sociology problem wearing an engineering costume, and it’s the one i’m best at.
before frameworks, and after.
i started building interfaces before "frontend framework" was even a settled term — jquery, hand-rolled state, css that fought you every step of the way. then came the framework decade: angular end to end, enough react and vue to be dangerous, ngrx and redux for state that needed real discipline, component libraries and design systems instead of one-off pages, and tests, performance and accessibility that had to hold up in production — not just look right in a demo. i designed as much as i coded too — years of hands-on figma and adobe xd work built the instinct for what belongs in front of a user, even though these days that means reading a spec fluently, not drawing one, because a technically correct interface nobody wants to use isn’t actually done.
that decade taught me the thing a lot of ai-first engineers skip: taste. knowing when a pattern is right for the people using it, not just correct on paper. now the tools have changed again — i build with ai assistance the way i once learned to build with frameworks, and the shift feels familiar rather than threatening, because i’ve already lived through one generational rewrite of how this work gets done.
that’s also where the mentoring comes from. i’ve watched this field reinvent its own tooling every few years, and the people who stay useful are the ones who can translate — between old code and new, between what a model suggests and what actually belongs in production, between an engineering team and the humans who have to live with what it builds.
What he runs now.
Frontend & Product Engineering
Ten years building and shipping production frontends — Angular end to end, enough React and Vue to be dangerous, state management (NgRx, Redux, signals) that needed real discipline, component architecture and design systems instead of one-off pages, micro-frontend architecture where a single app stopped fitting the org chart, testing, performance and accessibility as part of the build, not an afterthought bolted on before launch. Design was never separate from that either: years of hands-on Figma and Adobe XD work built the instinct for what belongs in front of a user — these days that shows up as reading a spec fluently, not drawing one. This is the base everything below stands on.
Systems Architecture
Before any of the three below, there’s this: what are you actually building, and where do its edges sit? I document architecture decisions and system boundaries the way arc42 asks for, so the next person — or the next me — knows why a system looks the way it does, not just what it does. Domain boundaries are the part I’m still getting more deliberate about as systems outgrow what one team can hold in their heads. Skip this layer and the other three are just guesses dressed up as engineering.
AI Product Engineering
I build products around large language models: retrieval-grounded assistants that answer from a company’s own data instead of guessing, agentic workflows that chain tools and decisions, and self-learning retrieval systems (vector search on Postgres) that improve their own context over time instead of staying frozen at a one-time embed. The goal is always the same — an AI feature that’s actually reliable enough for someone to depend on, not a demo that impresses once.
Infrastructure as Code
Everything I build gets deployed the same way it gets reviewed: as code. I work with OpenTofu and Bicep/ARM for provisioning, Docker and Kubernetes for running workloads, and CI/CD pipelines that turn a merged change into a deployed, observable system without a manual step in between. Infrastructure-as-code isn’t a nice-to-have for AI systems — it’s the only way to make what a model can access, and what it can’t, something you can actually prove.
Governance & Sovereignty
The riskiest part of adopting AI inside a real organization isn’t the model, it’s the lack of a policy layer around it. I build that layer: real-time compliance and governance enforcement for LLM systems — from simple regex-level rules up to specialized small-model agents — plus learning, provider-agnostic model routing that steers requests based on a company’s own requirements instead of a static leaderboard. The result is AI adoption an organization can actually control: who can use it, what it can see, and what happens when it’s wrong. It’s not a principle I only apply to clients — my own infrastructure runs the same way: self-hosted, on my own cloud, based in Germany, right down to running my own Matrix homeserver instead of a US chat platform. Independence from the big American providers, data privacy by default, and a more open, democratic internet aren’t a pitch for me — they’re the baseline I build from.
The stack.
ai / llm
infrastructure
frontend
craft
The record.
Senior Software Engineer at Makonis
Responsible for front-end architecture and, increasingly, for the AI systems and infrastructure-as-code behind our products — including applied work on real-time governance and policy enforcement for LLMs. I mentor junior developers and work directly with clients, turning ambiguous requirements into production systems.
Full-Stack Engineer at Sascha Wolff
Front-end (mostly Angular) and back-end (Node.js, MongoDB) on a small, senior team — the training ground for owning a problem end-to-end instead of a single layer of the stack, across every stage of the product cycle.
Co-founder of BreakfastClub U.G.
Financed through a one-year scholarship by Forschungszentrum Jülich, we built an application connecting local companies with breakfast providers.
Co-founder of Kusuri Company
We adapted the PillPack model from the US for the German market. The proof-of-concept performed well; we ran into legal obstacles that ended the project.
Master of Arts in Sociology
Westfälische Wilhelms-Universität Münster. Analysis of the social structure of modern institutions and organizations. Worked as a research assistant to Dr. phil. Gallina Tasheva.
Bachelor of Arts in Politics and Society
Katholische Universität Eichstätt-Ingolstadt. Politics and society, focused on organizational and industrial sociology. Worked as a research assistant to Prof. Dr. Joost van Loon.
why work with me.
you get someone who shipped production frontends for a decade, designed before he built, and spent the last few years turning ai from a novelty into infrastructure a real organization can trust — not three different people you’d have to hire separately.
i translate instead of picking one discipline and ignoring the rest: design and engineering, the old stack and the new one, technical depth and the people who actually have to live with what gets built. that’s the whole pitch.
get in touch — info@danielzenzen.eu