daniel zenzen — ai systems & infrastructure-as-code

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.

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.

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.

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.

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.