Machine Learning

I build the ML that runs after the notebook closes.

Training a model was never the part that kept me up at night. What kept me up was everything after: a workload of billions of calculations that has to be spread across a Kubernetes cluster, a model that has to answer behind a real API, a research script that has to become something I can put tests around and page someone about. So that’s the work I’ve made my specialty — Ray and KEDA for distribution, PyTorch for the deep learning, and ML.NET when the model needs to live inside a .NET codebase and give the same answer every time.

Hire Me Show Me the Receipts

Elbow-to-Elbow with Data Scientists

The data scientists own the math. I own everything else.

On every ML engagement I’ve done, the gap was the same: a data science team with a model that works in research, and nobody whose job it is to make that model finish, ship, and keep running. That’s where I sit. I bring 20+ years of enterprise engineering to their prototypes — feature sets of 200K+ features, workloads of hundreds of millions to billions of calculations — and turn them into distributed, tested, monitored systems. I don’t second-guess their algorithms; I make their algorithms survive production.

The ML Work I Actually Do

Six areas I’ve learned the hard way — each one behind a system that shipped.

Distributed ML on Kubernetes

The first time I watched a job that needed hundreds of millions to billions of calculations crawl on a single box, I stopped sizing hardware and started sizing queues. Now I spread the work across Kubernetes with KEDA event-driven autoscaling and Ray clusters on AWS EKS, letting queue depth — not a capacity guess — decide how many workers exist.

Deep Learning in Production

I’ve built LSTM networks in PyTorch and run DeepAR forecasts, but I refuse to deploy either on reputation alone. I put them in ensembles next to ARIMA, Holt-Winters, and Prophet and let the numbers argue. Sometimes the neural net wins; sometimes a classical baseline embarrasses it. Either way, I know before production does.

Feature Engineering at Scale

I’ve built ranking engines that grind data-science models through feature sets of 200K+ features, and the lesson that stuck was to never pick the distribution layer by fashion. I ran Ray/Anyscale, KEDA, and Azure Durable Functions head-to-head on the same workload and let the benchmark make the call. The pipelines that feed these models

ML in .NET

When the rest of the system is .NET, I don’t bolt on a Python sidecar — I run ML.NET time-series forecasting (SSA) and SDCA regression right inside the application. Same inputs, same outputs, every run, which means I can write real unit tests against the model instead of hand-waving about tolerances.

MLOps & Model Serving

A model nobody can call is a science project. I put mine behind REST APIs with job tracking and monitoring, train and serve on SageMaker when it earns its keep, and handle the unglamorous wiring — Kong middleware included — because I want an ML service to be as boring to operate as any other service I run.

Partnering with Data Science

Handing a data scientist’s prototype to production untested is how outages get named after you. My habit is to wrap the math in unit and integration tests, make the pipeline reproducible end to end, and give the data-science team engineering review they can actually build against. For what I do with LLMs and agents, see AI & Machine Learning

Where I’ve Actually Done This

Three systems I built and shipped: distributed ranking for industry, forecasting ensembles, and ML.NET in my own SaaS.

Industrial · Distributed ML

Koch Industries — Ranking & Prediction at Billion-Calculation Scale

The ranking engine here had to push data-science math models through feature sets of up to 200K features — hundreds of millions to billions of calculations. I didn’t start on EKS; I started with a RabbitMQ + minikube POC on my own machine, proved the sharding worked, then moved to KEDA on AWS EKS only after benchmarking it against an Anyscale/Ray prototype of the same job. The prediction side was an LSTM algorithm in PyTorch on Ray.io for parallelism — I designed it sitting with the data scientists, and I wrapped the whole thing in unit and integration tests before it went anywhere near production.

See the full engagement history

Industrial · Forecasting Ensembles

Distributed Forecasting Ensembles on EKS

For an industrial forecasting platform, I built production-capacity forecasting as an ensemble — ARIMA, Holt-Winters, Prophet, LSTM, and DeepAR all competing on the same series — because no single model was trustworthy across every business unit. I put it behind REST services and parallelized it on EKS with KEDA; the real win wasn’t accuracy, it was that the nightly forecasts finally finished on schedule.

See the portfolio

FinTech SaaS · ML.NET

Grade My Investments — Deterministic ML.NET in Production

In my own product, I grade US stocks with ML.NET SSA time-series forecasting and SDCA regression — deterministic on purpose, so I could pin the math down with 695 tests — and I let Claude sit on top purely as the language layer. If I could hand one pattern to every team: keep the ML core deterministic and doing the math, keep the AI layer explaining, and never let them swap jobs.

See the architecture

Got a model stuck between research and production?

That gap is where I work. Whether it needs a Kubernetes cluster under it or a deterministic ML.NET core inside your .NET stack, I’ll get it finishing, tested, and served. Corp-to-Corp engagements out of Dallas / Ft. Worth.

Start a Conversation See the Portfolio Client Case Studies at Leopard Data