ABOUT
How I Work
Operational independence
Open-source dependencies, Linux on commodity hardware, and version-controlled infrastructure code are three expressions of the same discipline: bounding the cost of changing your mind to your own engineering capacity rather than to a vendor's discretion. Picking PostgreSQL over a proprietary managed database, RedPanda over Confluent Cloud, bare-metal Kubernetes over a hyperscaler — these are not stylistic preferences. They are decisions about whose schedule a future migration runs on.
Concretely: 51 Kubernetes deployments, 26 manifest files, Ansible playbooks for health checks and zero-downtime rollouts, three netcup VPS instances costing less per month than a single managed Kubernetes cluster on any major hyperscaler. If the system can't survive a disk failure followed by a clean rebuild, it isn't infrastructure yet — it's a configuration that happens to be running.
Mathematical literacy before the library
7,400 lines of Rust for cointegration, PCA, spectral analysis, and network analysis — not because scikit-learn doesn't exist, but because when an Engle-Granger test returns a p-value of 0.03 on a pair that's clearly diverging, you need to know why. Non-stationarity in the test window? Sample size? Structural break? Black-box libraries don't tell you, and statistical methods you can't explain are statistical methods you can't trust.
The library is the last step, not the first. First the eigenvalue problem, then the Marchenko-Pastur distribution, then the actual failure modes in the data. Then the decision: does the off-the-shelf implementation handle those failure modes, or is it worth building something that does? Most of the time the off-the-shelf path is correct. Sometimes it isn't, and the difference matters.
Production pragmatism
Rigor and pragmatism are not opposites. The math is what tells you when the cronjob is enough. Knowing the underlying methods is what makes it possible to decide that a flat file beats a database here, that a cron beats Airflow there, that a bash script beats a microservice almost everywhere it's tried. The right tool is the one that runs at 3 AM without intervention — not the one that looks best on the architecture diagram.
My current system uses 80 TimescaleDB tables because that is what the workload needs, and Makefiles plus Ansible because they are battle-tested, transparent, and legible to someone who has never seen the codebase. Over-engineering is a failure mode in the same way under-engineering is — both produce systems that don't survive contact with reality, just on different timelines.
Automate the path to production
Every deployment reproducible. Every configuration versioned. Every environment rebuildable from a git repository. That is the minimum standard for running anything in production — not a principle, not a preference. Code that can't be deployed from a script can't be automated; what can't be automated doesn't survive sustained operation. That's the bar.
Infrastructure literacy — Linux, scripting, the ability to build what you need instead of subscribing to it — is the skill that gets more valuable as more of it gets abstracted away. AI-assisted tooling raises the ceiling for engineers who understand the underlying systems, and lowers the floor for those who don't. The compounding effect over a decade is going to be substantial.
Background
Twenty years of professional work. Seven in mechanical engineering — test stands, measurement technology, data acquisition. Thirteen in data engineering and architecture, mostly inside regulated or high-availability environments across finance, automotive, life sciences, and industrial systems. The two halves carry through every system I build: physical-systems thinking on the engineering side, regulated-data discipline on the architecture side.
Now independent. The enterprise years taught me how to build things that survive contact with reality. The independence lets me build them the way they should be built.
What I Take On
Data architecture reviews. Production data platforms, schema design, observability, and the operational tax of the choices already made. Useful where a team has shipped fast, the system runs, and the next set of decisions is starting to look expensive.
Cloud cost and repatriation work. Bounded analyses of where workloads belong — hyperscaler, managed open-source, bare metal — with a bias toward the architecture that gives the team the most optionality at acceptable cost. Sometimes the recommendation is to stay. Sometimes it is to leave. The answer depends on the workload, not on a preferred conclusion.
Quantitative analytics infrastructure. Time-series stores, signal-processing pipelines, statistical model deployment, and the operational engineering around models in production. Built for trading desks and research teams that want their analytics infrastructure to be a strength rather than a liability.
Independent technical assessment. Second-opinion architecture work, vendor-selection due diligence, and risk review for systems heading toward — or already running in — production. Useful when an internal team needs an external perspective they can act on.