Eight years building the systems that keep running when nobody is watching them. Payments, energy markets, equities, retail, logistics.
Every engagement below has ended with something the client can run without me. That is the actual deliverable; the code is how it gets there.
The services your product runs on — designed for the load you actually have, tested on the paths that would cost money, and documented well enough that the next person doesn't need me.
Get off manual deploys. Containers so every environment runs the same thing, Kubernetes manifests so the cluster state is written down, a pipeline so releasing stops being an event.
Scheduled work that collects, evaluates and then does something — including placing real orders in real markets. Built with a simulation stage in front and alerting behind, because both ends matter.
For a system that has outgrown its shape. I find the seams the business already has, split along them in stages, and keep the thing serving traffic the entire way — the job I led on a live payment gateway.
One week reading your system and telling you the truth about it: a written report, the risks in priority order, rough cost against each, and a call to walk it through. The cheapest way to find out whether you need any of the four above.
A CV tells you where someone has been. These are the calls I make once I get there — the closest thing to a preview of working together.
Most monoliths get broken up along whatever boundary is easiest to see in the repository, which is why the resulting services still have to be deployed together. The seams worth cutting are the ones the business already has — the places where two parts of the company would describe the same word differently.
Zibal Led the decomposition of a live payment gateway into microservices, 2020–21
Environments that differ are a whole category of bug you can simply decline to have, and they're the category that eats the most time to diagnose because the evidence is never in the code. Docker first, then everything else — it makes every later measurement trustworthy.
Zibal, Pyango, Vgang Dockerised each platform ahead of the performance and scaling work
Every team has a theory about what's slow, and the theory is usually about the part that was hardest to write rather than the part that's actually hot. Load testing settles it in an afternoon and saves a fortnight of confident optimisation in the wrong place.
Brain Shuttle Locust load tests to find and clear real bottlenecks, 2023–24
Plenty of systems that behave like scheduled work get built as always-on services, then spend most of their life idling and most of their incidents on the state they accumulated while idling. Batch jobs start clean, finish, and either succeeded or didn't.
Energy trading platform Trading pipeline as GCP container batch jobs, orchestrated from GitHub Actions, 2024–25
Async is a tool for a specific shape of problem — many connections, mostly waiting — and a tax everywhere else, paid in debugging. Real-time tracking earns it. A form submission does not.
Rahpa Tornado backends for live location tracking, alongside conventional Django elsewhere, 2017–20
A job that finished slowly is not a job that failed, and a system that pages you for both will eventually be a system nobody reads the pages from. The useful question is whether this run looks like the runs that worked — which means you have to have been keeping the metrics all along.
Equities & energy platforms Health metrics aggregated across each pipeline, with anomaly alerting on daily runs
Eight years, five companies, two clients under NDA and named by sector.
Built for myself, mostly to learn the hard part properly: NeetCoders (Docker-sandboxed code execution behind RabbitMQ), CoffeeChat (etcd leader election and real-time routing), SmartTrader (a four-stage Forex pipeline on AWS), and a file-based ORM exploring Python metaprogramming.
I started with Python and JavaScript, drifted into Go and infrastructure, and ended up spending most of my career on the unglamorous half of software — the part that has to still be running tomorrow.
That shapes the order I do things in. I want the failure modes before the feature list. I put metrics in at the start rather than after the first incident, because a system you can't observe is a system you're guessing about. And I write tests for the paths that would cost real money if they broke, which is a shorter list than everything and a much longer one than nothing.
I've been the only backend engineer on NDA trading systems and one of several on product teams, so I'm equally comfortable owning a domain end to end or joining an existing codebase and respecting its conventions instead of rewriting them on arrival.
For a few years I've also taught Python, Go and JavaScript to beginners at Master Your Courses — mostly teenagers and career switchers. It remains the fastest way I know to find out whether I actually understand something, and it's why I write everything up as I learn it.