About
I am a software engineer. I have been building production systems since 2013, leading teams that build them since 2016, and for the last couple of years I have been focused almost entirely on AI — agents, retrieval systems, LLM applications and the automation around them.
Why the order matters
There are a lot of people selling AI right now who arrived at it from marketing, or strategy, or from a course. That is not a criticism — it is a description of a market that grew faster than the supply of people who had already been building systems when it happened.
But it does create a specific failure mode. Someone recommends an AI project without knowing what it will cost to integrate with the systems you already run, what your data will do to it, or what happens operationally when it is wrong. The recommendation is fine in the abstract and expensive in practice.
I came the other way round. I spent over a decade building and leading the delivery of software — mobile applications, enterprise platforms, real-time systems fed by hardware in the field, internal tools, integrations between systems that were never designed to talk to each other. Then AI became genuinely useful, and I have spent the last two years applying it.
That order is the whole of my argument. I know what it takes to put something into production and keep it running, because that is what I did before AI made it fashionable.
What I actually do
Most of my work starts with a business that suspects there is value in AI or automation and cannot tell which of the ideas in front of them is real.
So I go and look. I sit with the people doing the work and map how it genuinely runs — including the manual steps that only exist in someone’s head, and the spreadsheet that quietly holds the process together. Then I sort what I find into things worth automating, things that need an integration, things where the process itself is the problem, things where the data has to be fixed first, and the smaller set of things where AI genuinely earns its cost.
Then, usually, I build it. That is the part that separates this from a consulting report, and it is also the part that keeps the recommendations honest: it is a great deal harder to recommend something impractical when you are the one who has to implement it.
Where I have come from
I started in the Microsoft stack — .NET and SQL Server — and moved outward into PHP, Java, Android and eventually Python as the work demanded. Along the way that meant native mobile applications on both platforms, backend services, real-time systems taking continuous data from devices in the field, enterprise integrations, and a long run of internal platforms and automation.
From 2016 I was leading as well as building, and from 2019 running software development across cross-functional teams of frontend, backend, mobile and QA engineers. I have never stopped writing code, which is deliberate: I do not think you can make good architectural decisions for very long once you have stopped living with the consequences of them.
More recently that has included large-scale data platform work built on streaming and analytical databases, and the AI work that now takes up most of my attention.
Credentials, for what they are worth
An MSc and a BSc in Software Engineering, and an AWS Certified Solutions Architect – Associate certification. I have served on a university corporate advisory committee and taught Android development at university level.
I mention these because people ask, not because I think they are the interesting part. The interesting part is the fourteen years of systems that had to work on Monday morning.
How I work with clients
Directly. There is no account manager, and the person on the first call is the person who does the work. That is the structural advantage of being one experienced engineer rather than an agency, and it is the main reason I have kept it that way.
I will also tell you when I think you should not do something — including when you should not hire me. There is a page about that, because it saves us both a call.