About me

Few engineers work alongside people who build infrastructure at that scale so early in their careers, and that team had a lasting influence on me. I watched experienced engineers evaluate every decision about networking, concurrency and memory by its effect on latency and cost for the services that depended on it. I adopted that discipline, and it still shapes how I approach a problem. Before I commit to a design, I want to understand where the latency comes from, what each request costs and which tradeoffs I am accepting.

At SecurityHQ I applied that discipline to security analytics and took full ownership of the infrastructure behind it. I built and operated a MongoDB cluster on EC2 with sharding, replication, S3 backups and Ops Manager, and designed the time series collections, aggregation pipelines and ETL that ran on it. Owning the platform alongside the data changed my definition of finished. A successful pipeline run was the minimum. I was the one operating the system long term, so I designed for its failure modes and recovery from the start, and structured it so that others on the team could understand and work with it too.

As the platform grew to include ClickHouse and more complex Airflow orchestration, I held it to the standards of any production software. My DAGs are built around single responsibilities, reusable components and explicit failure handling, so another engineer can change them with confidence. I design data models around the queries they serve, since the model determines both response time and compute cost. In ClickHouse that means treating sort keys, partitioning and table engines as architectural decisions with measurable consequences for performance and spend.

Leading a team extended my responsibility from the systems to the decisions around them. I work with stakeholders to define requirements, align priorities and make tradeoffs explicit before they become surprises. When delivery is under pressure, I make expectations more precise. I set out what we know, what remains uncertain and what we can commit to. Stakeholders who understand the reasoning behind a plan can adapt when circumstances change. I give my engineers the same context, so they can make sound decisions independently.

I have realised that in 2026 you can’t get far without talking about AI, so here goes. I build full stack applications with AI agents. I direct them with established design patterns and clear architectural boundaries, and I review their output with the same rigour I apply to any code review. They have shortened the time between an idea and a working prototype. Accountability for what ships remains mine.

Cost awareness also guides my choice of analytical tools. Many workloads do not justify a distributed cluster. DuckDB, Polars and Apache Arrow handle substantial analysis on a single node, with zero copy interchange through Arrow. WebAssembly is where this gets genuinely fun for me, because it lets me move compute to the client. The warehouse does the heavy lifting once and produces the latest materialised rollup, which can still run to millions of rows. That result set ships to the browser as Arrow or Parquet, and from there every filter, drill down and regrouping runs locally in DuckDB Wasm. The user gets a responsive, interactive experience, and the OLAP warehouse is spared a steady stream of exploratory queries that would otherwise cost compute and compete for concurrency. My focus is the full path from the underlying data to a result someone can act on, and getting the split between server and client right is one of my favourite parts of that path.