Metrics I care about: Cost per task · Precision · Data lineage · Recall

I am a software engineer with a background in economics, interested in search and retrieval and the backend systems that support them.

• Currently a Member of Technical Staff at Doubleword
• Founder of Flux Search: freshness-first semantic search engine for developers and agents
• Previously: investor-startup matching at Evvolve & Partners; agentic datasheet search at ChipHub (Nvidia Inception); credential platform at Certie (Oxford University Innovation); VC analyst scouting the MENA region at YAS Investments
• Economics background with a focus on econometrics

Languages
Picking up
Infra & Backend
Frontend
Data & ML
Observability
Tools

Working on tagging, retrieval, and indexing decisions for Flux. I am particularly interested in the balance between throughput and latency, in prioritising cost per task, and in finding cost-effective methods to deliver better-quality and more explainable search systems.

• Model pruning with PyTorch, run inside a flywheel loop of prune, eval, retrain, to remove parameters that contribute little to output quality.
• Model quantization to shrink memory footprint and improve GPU utilisation at inference.
• Fine-tuning small encoders, including multi-head (Hydra) architectures where one forward pass produces the typed spans that a decoder-phase model, an ensemble of larger models, or another heavier approach would otherwise require. I would describe myself as fairly hype-resistant, aiming for the most efficient (even if that means it's unsexy) option for the task even when that bucks the token-maxxing trend.
• Matryoshka embeddings, quantization, and multi-modal embedding storage for high-quality retrieval across many ingested data types.
• Evaluating tagger architectures, weighing LM-based approaches with a decoding step against encoder-only alternatives, to minimise the computational cost of delivering high-quality, explainable output.
• Running reproducible, explainable eval suites across live-web data and static datasets, combining quantitative measures, qualitative review, LLM-as-judge grading, and commercial benchmarks.
• Data curation, moderation, and crawl frontiers, covering filtering, deduping, and joining datasets so training and eval reflect real traffic, prioritising high-quality and authoritative sources, moderation that keeps unsafe content out of the index, and signed-URL frontiers that coordinate revisit scheduling and politeness across workers.
• Data compaction and other methods to achieve token-efficient results.
• Model serving through ONNX deployment paths, batching, SIMD in the hot inner loops, and hardware sized against realistic query patterns.
• Choosing and designing the surrounding infrastructure for crawl, index, storage, cache, and observability, evaluating each swap on both engineering cost and unit economics.

Currently, I'm also exploring query expansion, query decomposition, and how to help LLMs know when they've arrived at a correct answer. In my free time I keep chipping away at Rust and reading retrieval papers. I also enjoy the operations side of team knowledge, stitching agents together to reduce friction between ideas and conversations, or setting up a note-taker that flags unclear moments and attributes decisions to the right people. Retrieval and context problems show up in many places, including search engines, team knowledge, agent workflows, and meeting notes. This way, I like to find where things break or could be improved and make efforts to improve them.

• I prefer Rust and Go over Python on the hot path for tail latency, GIL-free concurrency, and more predictable memory behaviour.
• I prefer measuring against realistic query patterns over headline benchmarks when evaluating tail latency and cost per task.
• I prefer to make something work first, then make it work fast, then make it work for a lot of users.
• For always-on systems like search, which balance precision and latency at high volume, the fundamentals matter early. Small decisions compound at scale.
• Concretely, I do not want to degrade the search experience because a cost was miscalculated, or index material that is harmful or low quality.
• As with music, if you can play an instrument slowly you can play it fast. Understanding a system carefully lets you scale it later.
• The biggest dangers to a project are the ones that can end it entirely, like losing team integrity or failing to get to market on time. Team alignment matters more than any single technical decision.
• I prefer building towards a big vision, however opaque, in small clear steps.

Together, these interests support the goal of building products where the technical choices add up to a fluid, commercially aligned user experience.

• Backend systems, including balancing latency tradeoffs
• Systems programming, mainly in Rust and Go
• Econometrics, mostly DiD, network analysis, and measurement in tech
• Finance, from venture to macro to equities