Real problems. Real trade-offs.
A selection of engagements across data, platforms, distributed systems, and delivery. Anonymised, and written around the decisions rather than the client. The reasoning behind a choice usually outlives the technology, so that’s what I’ve kept.
Restoring trust in a live game's revenue analytics
Rebuilt a trusted, repeatable analytics foundation after revenue reporting lost credibility.
A large-scale source-control and workflow-platform migration
Led the migration of hundreds of repositories and a major orchestration upgrade against a demanding timeline.
Designing a notification system for a high-concurrency multiplayer platform
Chose a pragmatic long-polling and Redis design over a fashionable one, fitting real platform and delivery constraints.
Observability tooling for cloud-hosted game servers
Built a C# metrics SDK and Unity integration to make dedicated game servers measurable in production.
Migrating a fraud-detection data source without losing trust
Moved a fraud-detection data source between providers while keeping operational and analytical outputs trustworthy.
I bridge domains, on purpose
My real value is carrying hard-won patterns from one domain into another. The write-ahead log that keeps a relational database consistent and the metrics that keep a low-latency Unity SDK honest are closer than they look, and I design across those boundaries rather than staying inside one of them. New domain, same questions: where are the bottlenecks, what scales, what fails, what’s the simplest thing that works, and what does it cost to run?
I’m most useful at the seams: between software and data engineering, between architecture and delivery, between what a client asks for and what they actually need. I’m not a specialist who wandered. I’ve worked across enough territories to know what good looks like in each one, and to connect concerns that are usually kept apart.
Principles that travel
I'm a generalist, so I don't lead with a favourite framework. I lead with how I work: a handful of engineering, design, and leadership principles I carry into every system I touch.
Fix the real problem, not the symptom
I dig until I find what's actually broken, then fix that, instead of band-aiding whatever's shouting loudest.
- Diagnose before prescribing
- Kill root causes, not alarms
- Find the real problem, not the one shouting loudest
- Resist the quick patch that quietly becomes permanent
Build for the next person
Systems outlive whoever built them. I design for the team that inherits the code, so it can grow instead of ossify.
- Extensible by default, with clear seams
- Readable over clever
- Decisions written down, not held in someone's head
- Design for the next person, not for today's deadline
DevX and UX are one craft
Whether the user is a customer or an engineer, friction is the enemy. I sweat the experience on both sides of the API.
- Paved paths and fast feedback for engineers
- Interfaces that feel obvious
- Automate the toil; impatience with inefficiency is a feature
Pragmatism over fashion
The right solution respects the time, budget, and team you actually have, not the one on the conference stage.
- Boring technology where boring wins
- Complexity only where it earns its keep
- Optimise for value, not elegance: would anyone actually pay for this?
- Ship, learn, iterate
Leave the team stronger
I judge a job by what's left behind: engineers who levelled up, standards that stick, momentum that outlasts me.
- Mentor by asking better questions, not handing out answers
- Give people ownership and candid feedback, not process and permission
- Decisions made in the open
- Unblocking people, not gatekeeping
None of this is tied to a stack. It’s the instinct you build after enough systems, in enough domains: knowing which of these matters most right now, and acting on it.
Have a difficult, important problem?
I’m happiest where the problem is unclear, several teams need to work together, and the outcome actually matters. If that sounds like your situation, let’s talk.
- Talk through a hard technical problem
- Scope a platform, data, or distributed-systems build
- Get a second opinion on an architecture or delivery plan
- A role or engagement worth a conversation