From client conversation to production AI.
I spent eight years in consultative sales and admissions. Alongside that I trained in data science and machine learning, and learned to ship software in the agent era. That combination won a paid engagement with a New Zealand qualitative-research firm working for government bodies: Stoa, a sovereign consultation-analysis platform I built end to end, now in pilot on real consultation data. I've since generalised the patterns into products and a methodology through Fridai, my consultancy.
I'm strongest at the translation layer: turning what a client actually needs into a working, evaluated, deployed AI system, and explaining the trade-offs in plain language on the way.
- 300,000+submissions on a single New Zealand bill; the volume that ended hand-coding and started this work
- 84.3%theme recall against a research firm's own analysts on live consultation data; the gap is over-assignment, not error
- 3 livedeployed systems you can open and use right now, listed at the foot of this page
- 700+commits across 11 self-directed repos, April to July 2026
- Stoa: sovereign consultation analysis (paid engagement, in pilot)
- Agora: feedback-analysis product with a runnable demo
- Website→demo delivery pipeline (two live deployments)
- FridaiOS: the operating layer I work from
Capabilities matrix → every claim linked to evidence.
Where I come from, and why it helps
- Route in
- Data Science and AI certification (AUT, 2024), taken before agentic coding tools existed.
- Sales and admissions
- Eight years, ending as interim regional admissions manager over a remote team.
- Before that
- Classroom educator, university student recruitment, recruitment consulting.
- Degrees
- BA (politics) and LLB, University of Otago.
I came into this from outside engineering, and the people I build for are outside it too. Before this I was writing sales reports and working to KPIs, coaching, running campaigns and events, reading marketing data, doing the admin nobody counts. So when I look at a workflow I can usually tell which parts carry real judgment and which are habit that outlived its reason. Sorting those two apart is the hard part of automating knowledge work, and it is not a technical question.
Most of my career has been explaining difficult things to people who did not ask for a lecture: values to eleven-year-olds, then engineering and science degrees to school leavers at a STEM-heavy university, then career changes into cyber security, data and software to working professionals. Alongside it I led a remote admissions team through an interim management stint, sold consultatively against a pipeline of several hundred new leads a month, negotiated placements in recruitment, and held the relationships with schools and partner universities. The client-facing half of this work is not something I picked up on the way to the technical half. It is most of what I did.
A law and politics degree earns its place in a field this regulated. Stoa exists because data-sovereignty rules barred the obvious cloud product, and the work ran through a government security standard and a public-sector RFP. Reading constraints like those as design inputs rather than obstacles is the same habit that degree drills.
The distinction that matters right now. A lot of people have spent a year or two with AI tools and arrived at a confidence the work has not tested yet. Mine has been tested. I trained in machine learning and the data engineering underneath it in 2024, before agentic coding tools existed: the theory first, the code written by hand. Then I built and delivered a platform with a load-bearing AI component to a government security standard, against a fixed deadline, and it is running on real data. Shipping something that has to survive a security review and a client who depends on it is a different education from building demos.
How I decide what to build
I start from why the business gets paid. Before any process map, I want to know what this team is actually good at, what the client is buying when they buy from you, and where the people doing the work think their judgment is being spent well. Then I map that against where the hours actually go. The gap between the two is the automation brief, and it is almost never the thing that was requested in the first meeting.
Most candidate use cases should be killed early, and saying so is half the value of the role. I rank them on operational leverage, regulatory exposure and how ready the team is to change how they work, and I kill the ones that only score on the first. The expensive failure is not a build that overruns. It is a system that ships, is quietly not used, and spends the organisation's appetite for the next three projects that would have worked.
Adoption is part of the build, not a phase after it. I have sat on the other side of a rollout, and I have run the training and the playbooks that make one stick. When I built AI tooling for the sales operation I worked in, the constraint was never the model. It was whether a consultant under quota pressure would trust the output at 4pm on a Friday. Design for that person or the project is decoration.
What governs the architecture
Eight positions I hold, and can show you where each one was earned.
- A person owns the decision; the machine owns the legworkAutomate up to the judgment call and stop there. Stoa proposes every theme assignment and an analyst confirms it, with a timestamped audit trail behind the result.
- Degrade, don't failWhen a model cannot answer well, return something less specific rather than something wrong. Stoa preserves "none of these" instead of forcing a match; the demo chatbots drop to keyword retrieval rather than answer from a stale index.
- Evals are the ship gate, not a QA afterthoughtGolden cases pass before deploy and again against production, because a system that passed locally is a different system once it is serving.
- Cost is a design inputModel choice, batching and routing get decided against a budget rather than discovered in an invoice. One engagement took a commercial alternative priced in the tens of thousands per run off the table.
- No single-provider dependencyInference pricing has not found its level and the subsidy will not last, so the apparatus points at whichever model is right this quarter.
- Build alongside what existsA new layer that runs next to the current stack, with the migration path written down, beats a rewrite nobody sponsored.
- Assume the input is hostilePrompt injection and identity probes are test cases that pass before ship, not incidents handled afterwards. On one build, checking the design against primary documentation caught an authorisation header leaking across a redirect while it was still a diagram.
- Auditable by the people accountable for itIn a regulated setting an answer nobody can check is not an answer, whatever the benchmark says.
What I think is actually happening
Capability got cheap; organisation became the scarce input. Software absorbed AI first partly through proximity to the labs, but mostly because its work was already written down, versioned and testable, which is the shape these models need. Everyone else gets the same tools and a faster flood of information with no way to hold it. That is the real problem in front of most businesses, and a better model does not solve it.
Velocity is the constraint now, and it cuts both ways. The same technology that floods a business with information is the only practical way to process it, so the choice to sit this out expired a while ago. But the rate of change also breaks the usual way of catching up: a model's account of how to build with models is always describing a moment that has passed, because it learned from commentary written before the thing changed. You cannot delegate your way to being current. Somebody has to be plugged in, checking claims against primary sources at the point of use, which is the discipline I built my working apparatus around rather than trusting anyone's recall, including my own.
The goal is to put the worker in the driver's seat. Not a tool that answers for people, but tooling and a way of working that lets them apply the thing they are actually paid for at higher rate and wider scope. Taste, knowing which question to ask, and holding direction over time do not get commoditised by a better model, and however far the frontier moves they remain the scarce input. Systems should be built to concentrate people on exactly that and take everything else off them. That is the whole argument, and FridaiOS is what it looks like built out, in daily use, with the engineering exposed.