Skip to main content

Technical domains

Expertise.

Six domains, and — at the bottom of this page — the lines I will not cross when describing them. Naming your own limits is cheaper than having someone find them in a technical interview.

01

Applied AI & GenAI

Building complete AI systems rather than demos — and building the tooling agents consume, rather than only calling APIs that already exist.

Systems

  • LLM systems
  • RAG pipelines, including hybrid RAG
  • LLM orchestration
  • AI agents & agentic workflows
  • Long-term memory systems
  • Evaluation frameworks
  • Guardrails
  • LLM observability

Protocols & tooling

  • MCP servers built, published and operated
  • MCP clients
  • Coding agents in daily use
  • AI tooling design

Inference

  • Self-hosted LLMs (Ollama)
  • Local GPU inference
  • Quantisation trade-offs
  • Privacy-first AI
  • Cost / latency / quality arbitration
02

Software & systems engineering

One core, many surfaces, one public contract — and the packaging discipline that lets other people actually install what you wrote.

Design

  • Software architecture
  • Backend engineering
  • API design
  • Distributed systems
  • Concurrency & async
  • Domain modelling
  • Design for reliability

Delivery

  • Python (primary language)
  • FastAPI
  • REST APIs
  • Python SDKs on PyPI
  • CLI tooling
  • Browser extensions
  • Monorepo & validation gates
  • Semantic releases
03

Infrastructure, DevOps & platform

The glue that decides whether an AI system survives contact with real users. Every incident I have driven to root cause ended in a pipeline check, an alert or an automation — not a patch.

Platform

  • Docker & containerisation
  • Proxmox & LXC
  • Kubernetes / k3s
  • Helm
  • Terraform
  • Linux
  • Networking

Delivery & operations

  • CI/CD (Forgejo, GitHub Actions)
  • Git-driven releases & multi-arch images
  • Monitoring & alerting
  • OpenTelemetry, Grafana, Elastic
  • SLI/SLO
  • Incident response & root-cause analysis
  • Backups & recovery
04

Linux & system administration

The deepest layer of this profile, and the one that took longest to start claiming out loud.

Depth

  • Arch Linux as daily production machine for ten years
  • Custom window manager wrapper around i3
  • ~50 distributions installed and broken
  • Package management & dependency conflict resolution
  • systemd, init, daemon authoring

Scale today

  • ~30 Linux systems administered at once
  • Debian, Ubuntu, Alpine
  • LXC containers, Docker containers, VMs
  • Encryption & TPM
  • GPU passthrough
05

Data & cloud platforms

Four years of enterprise data platforms in a regulated environment, from ingestion through to governance.

Platforms

  • Databricks
  • Spark / PySpark
  • Delta Lake
  • Unity Catalog
  • Lakehouse architecture
  • SQL

Cloud

  • AWS (platform of choice)
  • Azure & Power BI (narrow, real)
  • Ingestion pipelines
  • Streaming
  • Data governance & quality
06

Classical machine learning

Where this started, and still the reason the mathematics under a model is never a black box.

Methods

  • Time series
  • Anomaly detection
  • Supervised & unsupervised learning
  • Deep learning fundamentals
  • Statistics
  • Pandas, NumPy

Calibration

Where I draw the line

A profile is only as good as its weakest claim. These are the five places where the honest sentence is narrower than the one a keyword list would suggest — stated here so that nobody has to discover them later.

Kubernetes

+ what is true Hands-on in a personal lab environment — building, deploying and breaking workloads on a self-managed k3s cluster, plus the observability stack on top of it.

− what is not My production services do not run on it. They run on Docker under Proxmox. I have not operated Kubernetes at enterprise scale, nor as a shared service for other teams.

Observability

+ what is true OpenTelemetry, Grafana, Elastic and Helm deployed and run on my own cluster, with a first pass at SLIs and SLOs. Installation, configuration, queries, dashboards.

− what is not Not an observability platform operated for other teams, and not a formalised SLO practice sustained over years.

GitOps

+ what is true Git as the source of truth for configuration and releases: push- and tag-driven pipelines, semantic releases, multi-arch images, published packages.

− what is not No reconciliation operator — no Argo CD, no Flux — runs on my cluster. 'GitOps-style delivery', not 'a cluster reconciled from Git'.

MLflow

+ what is true Governance and supervision of MLflow projects on Databricks with Unity Catalog — I put the conditions in place and oversaw the work.

− what is not Not deep hands-on practice: experiment tracking, model packaging and registry were not my daily work.

Azure

+ what is true Real enterprise exposure: Power BI delivery and cluster management on a client platform, as the manager of that work.

− what is not Narrow — visualisation and operation, not Azure platform engineering. AWS is by a distance the cloud I am most fluent in.

The claims above are backed by things you can look at: the portfolio for what was built, the journey for where it was built, and the colophon for the stack serving this page.