Everything I build starts as a search for an existing answer. Sometimes there just isn't one.
How I got here
The short version: I kept ending up building the tool I actually needed instead of the one that already existed. The longer version starts with a game.
Knightmare is still active, just paused: an AI Game Master built to run a real, 1:1 tabletop RPG campaign — not a chatbot roleplaying a GM, an agent actually capable of running the table the way a human GM would. Everyone on the team plays TTRPGs; the AD and I are both GMs ourselves. Building its agent orchestration on LangGraph is what taught me exactly where it breaks down — the frustration that planted "I'll have to rewrite this" long before I actually did. We got a working proof of concept in front of real players, and the feedback was consistent: this needed real funding to become what it was supposed to be. So the team made a call — build something that pays the bills first, then come back to Knightmare properly funded. KGM Technologies' name is the receipt: pull the capitals out of KniGhtMare and you get KGM.
How I think about software
Systems survive real users
I've shipped software that outlives the demo. 90k+ lines running in production at KGM, a paying client depending on Notalyse — both had to survive real users and real edge cases, not a curated happy path. That's the bar I hold every system to before I call it done.
Boring infrastructure is a feature
The parts of a system nobody sees — deployment, data pipelines, the plumbing between services — get the least glamorous, most battle-tested pattern available, on purpose. Creative risk belongs in the parts people actually feel; everything holding it up should be boring enough that it never makes the news.
Honesty about limits
I'd rather tell a client something won't work before we build it than let scope quietly explode after. The fastest way to lose a team's trust is confidence you haven't earned, so I say what I actually know and flag what I don't.
Solving problems that no one has isn't a boast, it's a byproduct of how I process new problems. Every project gets treated as its own edge case — its own constraints, its own risks, its own shape. I look for what already exists first: most of what I build borrows an existing idea and gets bent around the real constraints of the problem in front of me. Building from scratch is rare, reserved for when nothing else actually fits. That instinct — pulling the same underlying pattern out of a legal-tech compliance platform, a five-person game project, and an agent framework — is the same cross-domain connection that shows up as hyperfocus once I'm deep in one of them, and directness when I tell a client the truth instead of a sales pitch.
How I use AI
I treat AI the way I treat any tool: leverage, not a replacement for judgment. This portfolio is the proof, not just a claim — every architectural decision, every rejected draft, every word of voice on this page was mine to make; the execution was a collaboration with an AI agent I directed and reviewed the way I'd review a very fast, very literal engineer. I don't romanticize it or dismiss it — I've built agent orchestration frameworks professionally, so I've seen exactly where it moves fast and exactly where it still needs a human holding the actual understanding of the problem.
What I'm working on now
- KGM Technologies
- Notalyse
- Personal R&D projects
What I'm not
I'm not a visual designer — I'm getting better at it, but interface polish will probably never come as naturally to me as backend architecture does. I also haven't managed a large engineering team; most of what I've built, I've built solo or with a handful of people. I think I'd be good at it — I just haven't had the chance to prove it yet. And I'm not a salesperson: closing something by managing someone's feelings isn't a skill I've built. What I do have is a knack for explaining the stakes — breaking a problem into real options (cheap, average, expensive, each with the trade-offs that come with it) so someone can actually decide for themselves instead of being sold to.
Outside of code
Outside of code, I keep aquariums — real biotopes, not decoration: balancing water chemistry, plants, and fauna into something that actually holds together over time. Same instinct as the day job, aimed at fish tanks instead of servers.