About
Two careers that turned out to belong together
An interest in data took me into machine learning and software. At the same time, my day job taught me how people buy, decide, explain difficult things and keep imperfect operations moving. Those threads met when I began building AI automations inside the admissions team where I worked.
I now build applied AI systems from the first client conversation through evaluation and deployment. The communication experience is not a substitute for the engineering. It helps me work out what deserves to be built, then get it into use.
Two threads, then one practice
People and operations
- Coach and educatorExplain, observe, adjust
- University recruitmentRelationships and evidence
- Sales and admissionsPipeline, management, process
- Applied AI deliverySystems people can use
Data and software
- Data interestAnalysis and automation
- Data Science & AI49 authored notebooks
- Client buildStoa and later systems
- Applied AI deliveryArchitecture through adoption
The overlap is the useful part: I understand the work before it becomes a specification, and I can build what follows.
Coaching and education
Built a year-round basketball programme, coached teams over several seasons, then taught 30 values-based lessons each week to more than 700 primary and intermediate students.
Recruitment and admissions
Managed school and university relationships, increased enrolments in one region by 15%, sold intensive technology courses and temporarily led a remote admissions team handling hundreds of new leads a month.
Data science and machine learning
Completed a professional Data Science & AI certification (AUT, 2024) while working full time. The course covered the statistics and data engineering underneath the current generation of tools, with code written before agentic coding became the normal interface.
Systems in use
Built admissions automations inside a live operation, then delivered a consultation-analysis application for a paying client. I separately designed and pattern-tested its sovereign hosting boundary. That work covers client discovery, architecture, implementation, evaluation and deployment.
Why the surrounding operation matters more now
What changes once the work is real
- 01
Find where the business earns its value
I compare the work people believe needs their judgment with the work consuming their time. The difference is usually a better automation brief than the first request.
Admissions → - 02
Stop before the consequential decision
The system can gather evidence and prepare the action. A named person still approves it when the result affects a customer, applicant or public record.
Stoa → - 03
Test the system that will actually run
Evaluation, failure handling and cost belong in the build. A prompt that worked once is not evidence that a production workflow is safe to ship.
Demo pipeline → - 04
Design for the person using it late on a Friday
Training and workflow fit are engineering constraints. If the user does not trust the output under pressure, the project has not solved the problem.
Admissions → - 05
Kill the use cases that only score on leverage
I rank candidate use cases on operational leverage, regulatory exposure and how ready the team is to change how it works, and I kill the ones that only score on leverage. 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.
Admissions →
A law degree in regulated AI work
My degrees are a BA (politics) and an LLB from the University of Otago. In a field this regulated the law degree earns its place. 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 the degree drills.
Open to where this range is useful
I am open to a wide range of roles, including work that is not labelled AI or engineering. I have moved between technical delivery, operations, sales, education and research, and I am comfortable being useful wherever that combination fits.
Some roles will need someone who can build. Others will place more weight on discovery, communication, coordination or improving how a team works. I can contribute in either direction, and I do not need the job title to match this portfolio exactly.
The job title matters less to me than doing useful work, learning quickly and contributing to the team.