The Journey
Designer-turned-AI-Engineer — the long way round, and why I build the way I do.
A kid and a QBasic prompt
My first taste of code was QBasic — the little interpreter Microsoft tucked into MS-DOS and the early Windows discs. I was eleven, maybe twelve, and something clicked: you could type instructions and the machine would just… do them.
Visual Basic came next, and with it a very particular thrill — building software that looked real. Not a toy: a proper window, buttons that clicked, an installer. I'd burn it to a CD, design and print a label and a case insert, and hold this finished thing in my hands. Shipping, before I had a word for it.
Around the same time I fell just as hard for the web. MS FrontPage was my way in — I taught myself HTML and CSS by pulling pages apart, and put sites up on GeoCities. This was the era of laying everything out with frames and faking rounded corners by hand, slicing up images one painstaking table cell at a time.
Learning to make things intentional
I took the design route — through high school and then a diploma in Graphic Design at Natcoll. I learned craft: type, hierarchy, colour, and the discipline of making something look deliberate rather than accidental.
I thought I was becoming a graphic designer. I was — for a good stretch I lived a whole second life in design and marketing: brand identities, logos and packaging shipped for real clients, some of it still out in the world and working more than a decade later. That wasn't a detour. Building brands taught me exactly what good products need — a sharp promise, an audience you genuinely understand, and craft that earns trust in the first few seconds. It's rich design and marketing experience that transfers straight into building products people actually adopt.
And design left me with something that mattered more than the job title — a stubborn instinct that how a thing feels to use is part of the engineering, not a coat of paint applied at the end.
Slipping into the browser
Working as a designer at StudioQ, I got back into building for the web — CSS3 had finally landed, and those rounded corners I'd once faked with a folder full of sliced images were suddenly a couple of characters. The catch was IE6, still clinging to its own private dialect, so I lived the whole slow march of browsers grudgingly conforming to a standard (thank you, Chromium).
From there I slipped sideways from CSS and HTML into JavaScript — first to make the designs real, then to build the systems behind them. That's when it spiralled. Front-end became systems thinking; systems thinking became architecture.
On the side I was running my own venture, playing product owner and getting my hands dirty with graph-database modelling long before it was fashionable. The designer never left — I just kept following the problem further down the stack.
Component libraries, leadership, and graphs
At VizExplorer I went from senior front-end developer to team lead and Scrum Master — driving a shared component library, moving codebases to TypeScript, and learning that shipping well is a team sport.
Then Author-it, and Weta Digital — where I built an infinitely-scrollable, multi-dimensional scheduling timeline on Neo4j and GraphQL. I was quietly collecting the whole toolkit: design, front-end, back-end, graphs, testing, and how to lead people while doing it.
Graphs, agents, and a platform of my own
At BNZ I founded DIY — an internal developer-knowledge platform that grew organically from zero to ~2,192 users. I built a stateful LangGraph agent that reasons over a live Neo4j knowledge graph, a hybrid graph-vector retrieval engine, and a first-class MCP server so tools like Copilot and Claude Desktop can query it securely.
Now I'm growing that graph into something bigger: an organisational brain. A temporal knowledge graph, layered — one plane holds the real-world entities staff actually know and talk about, the people, teams, systems and processes; the others sit beneath it, semantic layers tuned for search and discovery. A memory of how the bank thinks, that its agents can reason over.
From there I extended the platform into the BNZ AI Marketplace — a home for shareable AI context: Skills, agent definitions, and the processes teams actually work by. It caught fire across the bank; developers, BAs and beyond adopted it, and it's fast becoming the hottest thing we have. A local Skills MCP server backs it, dynamically loading the right context — skills, processes, information — as staff work alongside their agents. The real craft has been staying ahead of a fast-moving industry without painting BNZ into a corner: build the best solution now, but keep it loose enough to pivot and conform to standards as they settle and new integrations open up.
Designer-turned-AI-Engineer, finally with the whole picture in view: the data model, the agent, the security — and, because of where I started, the experience of the person actually using it.
Still building, always
None of this switches off at five o'clock. Nights and weekends I've been building my own things — SquonkStack, Wallman, Context Garden, AIThreads — plus a drawer full of repos that never made it to a landing page.
And the other thing that never switches off: passing it on. When a friend, Jesse, came out of a web entry course wanting to build for real, I tutored him in React every week for a year — and to make it real we shipped an actual product together, a live voting app for ActiveFM radio. Sharing what I know and enabling other people to build software is a genuine passion of mine; it's why I mentor, coach, and speak wherever I've worked. (Teaching just doesn't pay — so I build, and teach everyone within arm's reach.)
That's the real throughline: I want to understand the entire process and every role in it, enough to take something from a vague idea to a working product myself. More than any single technology, I love solving problems. Give me a problem — or a fuzzy, high-level task — and I'm at my happiest.