Software Engineering 

My background is Computer Science with a focus on artificial intelligence, and my instinct is to ship rather than theorise. The work I'm proudest of is the work that ended up being used by someone who didn't know or care how it was built. That has included taking an AI-powered financial reconciliation assistant from a business requirement through to live production on cloud infrastructure — designing the conversational flows, wiring the integrations, and owning the deployment cycle inside a cross-functional team. The interesting part wasn't the model. It was everything around it: understanding a finance workflow well enough to represent it, handling the cases where the assistant should say it doesn't know, and making it reliable enough that people would keep opening it after the first week. Building for myself. I run a self-hosted automation stack on local hardware — containerised workflows handling scheduling, messaging, and calendar integration, with restart-on-failure supervision. It's not sophisticated. It runs continuously without me touching it, which is the part I'm actually proud of, because reliability is the thing that separates a project from a demo. I've also worked on bio-inspired system design — including a seismic early warning concept that used ant colony movement as a natural precursor, pairing IoT sensor monitoring with an AI anomaly-detection layer and an alerting path to disaster management authorities. That project taught me something uncomfortable and useful: a good idea that never gets built is worth less than a mediocre idea that ships, and most of the distance between the two is unglamorous engineering. The stack, and why I don't lead with it. I write Python, JavaScript, Java, C, and SQL. I work on AWS, in Docker, with Postgres and MySQL underneath, and I use Git the way everyone does. I studied OCaml, which I'll probably never use professionally and which changed how I think about writing functions anyway. I list these because people expect the list, but the specific tools rotate every few years and I don't think they say much. What transfers is the habit — reading documentation until something works, being willing to sit with a problem past the point where it's fun, and knowing when the right move is to stop building and go ask someone a question instead. What I want to build. Systems that get used. I'm less interested in technical elegance for its own sake than in whether the thing survives contact with real users doing unpredictable things. AI is where I've spent most of my time, and it's where that tension is sharpest right now — the gap between a model that performs well in evaluation and a product that people trust enough to rely on is enormous, and mostly filled with engineering judgment rather than research.