ABOUT
How I Work
Open source first
Not ideology — infrastructure strategy. Open source tools are inspectable, versionable, deployable anywhere, and not held hostage by a vendor's pricing revision. When I pick PostgreSQL over a managed database, or RedPanda over Confluent Cloud, I'm choosing tools I can run on my own hardware, debug at the source level, and migrate without asking permission. That's not philosophy, that's operational independence.
Every dependency is a risk. Open source doesn't eliminate that risk, but it gives you the option to fork, fix, or replace. Proprietary tools give you the option to pay more or rewrite everything.
Command line over GUI
A GUI is for presenting results. The command line is for doing the work. Everything I build is scriptable, automatable, composable. Ansible playbooks, Makefiles, shell scripts — these aren't the tools of someone who doesn't know better. They're the tools of someone who has to run 40 microservices on 3 nodes and can't afford to click through a dashboard at 3 AM when something breaks.
If you can't deploy it from a terminal, you can't automate it. If you can't automate it, it doesn't scale. If it doesn't scale, it's a prototype pretending to be production.
Understand the math before using the library
I wrote 7,400 lines of Rust for cointegration, PCA, spectral analysis, and network analysis. Not because scikit-learn doesn't exist — but because when your Engle-Granger test returns a p-value of 0.03 on a pair that's clearly diverging, you need to know why. Is it non-stationarity in the test window? Sample size? Structural break? You can't debug a black box.
The library is the last step. First you understand the eigenvalue problem, then the Marchenko-Pastur distribution, then the actual failure modes in your data. Then you decide whether the library handles those failure modes or whether you need to build something that does.
Production reality over textbook theory
Rigorous doesn't mean academic. It means knowing when a flat file beats a database, when a cronjob beats Airflow, when a bash script beats a microservice. The right tool is the one that works at 3 AM without human intervention, not the one that looks best on an architecture diagram.
My system uses 80 TimescaleDB tables because that's what the workload needs. My deployment automation uses Makefiles and Ansible because they're battle-tested, transparent, and I can hand them to someone who's never seen my system and they'll understand what's happening. Over-engineering is a failure mode too.
Infrastructure as code
Every deployment is reproducible. Every configuration is versioned. Every environment can be rebuilt from a git repository. That's not a principle — that's the minimum standard for running anything in production. If your infra can't survive a disk failure followed by a clean rebuild, you don't have infrastructure, you have a house of cards.
51 Kubernetes deployments, 26 manifest files, Ansible playbooks for health checks and zero-downtime deployments. When a node dies, the system recovers. When I need a second environment, I run a command. That's what production-ready actually means.
Linux-first
I run bare-metal servers, not because I enjoy sysadmin work, but because it's the economically rational choice for workloads that run 24/7. Three netcup VPS instances cost less per month than a single managed Kubernetes cluster on any cloud provider — and I control everything from the kernel up.
There's a broader point here too. The ability to run your own infrastructure, on your own terms, on commodity hardware, using open-source tools — that's independence. In a world where US cloud providers can change terms overnight and AI is making custom tooling accessible to anyone who understands the underlying systems, the value of knowing how things actually work keeps going up. The people who understand Linux, who can read a man page, who can build what they need instead of subscribing to what someone sells them — they're not behind. They're ahead of a curve most people haven't noticed yet.
Background
Started in mechanical engineering — 7 years in test stand and measurement technology, building data acquisition and control systems. That foundation in measurement data analysis, signal processing, and physical systems carries through everything I build today. When I design a data pipeline, I think about sampling rates, noise floors, and calibration — not just ETL patterns.
Moved into data engineering and architecture. Deutsche Bank (2022–2025): risk assessment data warehouses, 14 banking risk categories, Data Vault 2.0, BaFin regulatory compliance. Mercedes-Benz (2016–2020): ECU software distribution systems, cross-platform data marts, vehicle data pipelines. Plus CureVac, IDS GmbH, d&b audiotechnik — always at the intersection of data infrastructure and domain-specific engineering.
Now building quantitative systems independently. The enterprise experience tells me how to build things that survive contact with reality. The independence lets me build things the way they should be built.
Tools
Languages
Java 17, Rust, Python, SQL, Bash
Data
PostgreSQL, TimescaleDB, RedPanda, Apache Flink
Infrastructure
MicroK8s, Docker, Ansible, Linux
Frameworks
Spring Boot, Quarkus, Tokio
DevOps
GitLab CI, Argo CD, Grafana, Make
Methods
Data Vault 2.0, Cointegration, PCA, RMT
Outside Work
Jiu-Jitsu (black belt). Piano, drums, guitar — all by ear. Music production under the project "Lost Signals" (symphonic nu-metal, AI-generated). Three kids. Based in Germany.