Director of Technical Delivery & AI Engineer

Technical deliveryat scale, and AIin production.

A delivery team of fifteen engineers in Funraisin's largest region, a platform close to a thousand charities fundraise on, and launch dates set before anyone scopes the work. Alongside it, ZOSA: an AI product built alone, live on iOS, Android and web.

Experience
10+ years
Based
Australia · Remote
Timezone
AEST · UTC+10
Status

A career that began on snowy mountains found its way into software.

What started as a change of direction became six years of building things, breaking them, and working out how to make them better.

Today that means leading the team behind technology hundreds of thousands of people use.

And, alongside it, four years spent building AI systems alone.

Scroll down to learn more.

02How it started

By day, it is fifteen engineers, a large-scale platform and nearly a thousand charities relying on it to fundraise. Alongside that sits a one-person project, quietly built from scratch and now holding thousands of conversations. Two very different challenges, with each one bringing something back to the other.

The first is Director of Technical Delivery for Australia at Funraisin: the project delivery team, fifteen engineers in-region and offshore, in the region that is roughly 80% of the business. It is an agency built around its own product, so charities customise campaigns on top of it, and this team delivers that bespoke work, planned alongside the project managers and usually against dates set before anyone has scoped it.

The team gets the most attention. Small sessions rather than a broadcast all-hands, real questions about where somebody wants their career to go, and enough context for engineers to make the call without anyone above them. Honest conversation is faster than polite conversation, and you only get it once somebody trusts you.

It began in September 2020, joining as a graduate and spending the first year taking the platform apart: fifty admin modules, 275 routes, campaigns where an hour of downtime is counted in lost donations. Four promotions and one continent later, same codebase, now with the AI standards a distributed team builds against.

The pattern repeats away from work. Teaching skiing in a language picked up on the way, walking to Everest base camp, marathons, forty countries, a new language started from nothing. Slightly out of your depth turns out to be a comfortable place to live.

Then there is ZOSA: three and a half years, 819 commits, and nobody else on it. The reason has nothing to do with technology.

Suicide has taken people I knew, and people closest to my friends. Each time, nobody around them knew how bad it had got.
Why ZOSA exists
Measured

The day job, the product alongside it, and the years behind both

Funraisin
0+
Engineers led
The AU project delivery team, in-region and offshore
Funraisin
0
Promotions in six years
Graduate developer to Director, on the same codebase, across two continents
Career
0+
Years in technology
Including university, freelance clients and six years at Funraisin
ZOSA
0
Commits, built alone
Two repositories, every commit hand-tagged under a strict version scheme
ZOSA
0
Distinct development days
Roughly one day in three, across three and a half years
ZOSA
0
API endpoints shipped
Async FastAPI, 15 domain route modules
SystemNominal
Render pipeline
STATIC
WebGL context
ACTIVE
Device tier
HIGH
Pixel ratio cap
2.00×
Pointer
FINE
Reduced motion
OFF
Story progress0%
03What the work taught
  1. 01Judgement

    Write down why, not just what.

    A decision without its reasoning becomes folklore within a year, and the next engineer either repeats the mistake it avoided or deletes the safeguard it added.

  2. 02Product thinking

    Let them feel it before you ask for anything.

    Free users on ZOSA get long-term memory for their first three sessions, so the thing worth paying for demonstrates itself rather than being described. After that it stops learning, but never forgets what it already knew. Taking something away teaches a different lesson from showing somebody what more would look like.

  3. 03Security

    Enforce it where it cannot be bypassed.

    Client-side limits are user experience. Server-side limits are control. On a multi-tenant platform the cost of getting it wrong is somebody else's data, and they never agreed to the mistake.

  4. 04Cost discipline

    Ask the cheap question first.

    Before ZOSA calls a model it works out everything plain Python can work out in a millisecond, and spends the tokens only on what needs judgement.

  5. 05Standards

    Generated code is a draft, never a deploy.

    The first rule in the standards the delivery teams now build against. The failure mode is not obvious rubbish, it is plausible code written against constraints the model never saw.

  6. 06Systems thinking

    Automate what should never have been manual.

    An integration that needed a find-and-replace every January now reads the year from the database. The saved hours are not the point. Where the team's attention goes next is: away from typing out a pattern somebody already solved, towards deciding what the system should do. Managing that shift is most of the job now.

04Leading the work

Engineering ishalf the job.

The other half is a team that can decide on its own, landing work against dates that were never going to move.

Idea to live
  1. Idea

    A charity wants something the platform does not do yet.

  2. Discovery

    Scoping, effort modelling, and what belongs in bespoke work versus core.

  3. Architecture

    The final call on approach, made before the work starts rather than at review.

  4. Build

    In-region and offshore teams, building from reference material somebody maintains.

  5. Review

    Code review, security review, and the PASS or FAIL gate on anything AI-assisted.

  6. Delivery

    Release sequencing against live campaigns, with no quiet hour to deploy into.

  7. Iteration

    Client reporting in plain English, and what the last incident taught everyone.

How problems get solved

The same five questions, whether it is a timeout or a team of fifteen.

  1. 01

    Problem

    What actually needs solving?

    The stated problem is usually a symptom. What matters is the sentence describing the failure, not the ticket describing the annoyance.

  2. 02

    Challenge

    Why is it hard?

    Find the constraint that decides the design. Tiered repository access is not a technical constraint, and it shaped the entire AI standard.

  3. 03

    Approach

    What is the smallest thing that proves it?

    Prove the risky part first, cheaply enough to be wrong. There is no maintenance window on a live campaign, so sequencing is part of the design.

  4. 04

    Technology

    What gets built, and what does not?

    Move what varies into data. Two dimensions of the ZOSA style profile were built and then deleted, because they could not be measured honestly.

  5. 05

    Result

    What changed?

    Instrument it so the next regression names itself. A fix nobody else can verify is not finished.

Written to be acted on

A decision only counts once somebody else can act on it.

One call, five audiences, five different forms of the same facts. Written well, a project keeps its own momentum and nobody has to chase it.

  1. 01

    Offshore engineers

    Specs and standards written to be read in a second language, with nobody in the room to ask.

    Work starts the morning it lands, several time zones away.

  2. 02

    Project managers

    Scope, sequencing and honest estimates, with the risky parts named and scheduled first.

    They can commit to a date and then hold it.

  3. 03

    Charity clients

    Plain-English incident and change reports: what happened, what it means for their campaign, what happens next.

    They can explain it upward themselves, which is what they actually needed.

  4. 04

    Senior leadership

    Proposals framed commercially: effort modelled against revenue, resourcing stated, trade-offs named out loud.

    A budget conversation that can end in a decision rather than another meeting.

  5. 05

    The model

    Catalogues of what actually exists, real payload files, and constraints written to be followed rather than understood.

    The newest audience, and the one that turns a written standard into throughput.

The other half

Confidence to decide

Give the team the context, tools and standards to decide alone, then back the decision afterwards.

Knowing people properly

Small-group sessions instead of a broadcast all-hands. Knowing somebody beats managing them, and honest conversation is faster than polite conversation.

Mentoring & careers

Ask a developer where they want their career to go, then shape the work around the answer. Handing out tickets develops nobody.

Psychological safety

The first question asked is what is not working, and the answer stays in the room. It only counts once somebody tests that.

Technical strategy

Standards, tooling and direction for the largest region, plus support for the UK and US teams.

Architecture authority

The final call on approach for high-risk builds, given before work starts rather than at review.

Scoping & estimation

Effort modelling and sequencing for enterprise accounts, including the conversation about headcount versus the date.

Escalation & security

Technical incidents and client escalations both land here, including mid-campaign.

Production access

The senior tier of platform access: production database and SSH to client web servers. A level of trust, deliberately restricted.

05What it is built with

Six domains, one system.

The lines between them are the part that matters. Select a domain to see what it is built from.

COREFRONTENDBACKENDAIDATAPLATFORM
Domain

Core

Two stacks, both held at architecture level. Funraisin's platform, legacy PHP, customised per charity by the delivery teams. And ZOSA, a Python AI product owned end to end by one person.

Technologies
  • PHP 7.4 / 8.x
  • Python 3.12
  • TypeScript
  • SQL
All domains
06Things built

Five pieces of work,start to finish.

One product built alone, four pieces of client work, and the same five questions asked of each: what was actually wrong, why it was hard, what was done, what it was built with, what changed.

Platform clients

Major clients from the AU, UK and US regions.

UNICEF
WWF
Greenpeace
Cancer Research UK
Mental Health UK
Alzheimer's Association
Race for the Kids
STEPtember
The Push-Up Challenge
Cancer Council
Camp Quality
01/ 052023 - present
The ZOSA web app: an onboarding screen offering encrypted, private mental health conversation.
The ZOSA iOS app home screen, showing conversation entry points and a daily check-in.

ZOSA

An AI product on iOS, Android and web. Designed, built, shipped and sold by one person. Every line of it.

Six providers behind one interface, a memory that holds somebody across months, real-time voice, and encryption its own author cannot break.

Role
Architect, sole engineer, product owner
Scale
120 endpoints, 6 providers, 14 models, 3 platforms
Impact
Live on three platforms, thousands of conversations, paying repeat subscribers
  • Python 3.12
  • FastAPI
  • LLM orchestration
  • Vector retrieval
  • WebRTC realtime
  • React Native
  • Firestore
  • AES-256-GCM
  1. 01Problem

    Suicide had taken people close to home, and each time nobody around them knew. Software does not fix that, but it can sit in the gap: one hour a week with a therapist, and nobody there for the other 167.

  2. 02Challenge

    A model that forgets is not a companion. Continuity across months means solving retrieval, context and cost at once.

  3. 03Approach

    Treat the model as one component rather than the system, and design the layers around it: what is retrieved, what never reaches it, and what happens when it is wrong.

  4. 04Technology

    A 120-endpoint async FastAPI service, six providers behind capability tiers, hybrid retrieval over Firestore vector search.

  5. 05Result

    Thousands of conversations across three platforms, on an architecture that came from psychiatry papers rather than product blogs.

02/ 052025 - 2026

AI Ways of Working

Turning AI from something individuals were quietly getting away with into something a distributed team can be trusted with.

Four regions, four different assistants, and all of them writing textbook framework code. On a bespoke platform that code looks right and fails review.

Role
Author and owner
Scale
Fifteen engineers on the AU delivery team, four regions
Impact
Output quality stopped depending on which developer picked up the work
  • Claude Code
  • Subagent design
  • Prompt & context engineering
  • Review workflows
  1. 01Problem

    AI assistants write framework-default code. On a bespoke platform that is wrong in ways which pass a glance and fail review.

  2. 02Challenge

    Tiered repository access across four regions: a standard assuming full access solves it for the wrong half of the team.

  3. 03Approach

    Ground the assistant in the real codebase. Catalogue what exists so it never has to invent.

  4. 04Technology

    A versioned reference pack, and a four-stage build-and-review pipeline with a person at every checkpoint.

  5. 05Result

    AI-assisted work is now reviewed, conformant and auditable, with or without core file access.

03/ 052026

Attack Response & Remediation

An automated attack on a live national fundraising campaign, mid-event, with no quiet window to deploy into.

High volume through public forms from a single source, against a platform running a live campaign where downtime is counted in lost donations.

Role
Incident lead
Scale
Four national platforms brought to one standard
Impact
Highest-priority review item closed; attack surface permanently reduced
  • WAF response
  • Log analysis
  • Attack surface reduction
  • Staged rollout
  • Stakeholder reporting
  1. 01Problem

    An automated attack on a live national campaign platform, mid-event, driving high volume through public forms.

  2. 02Challenge

    Stopping it without stopping donations, where a false positive is a supporter who gives up halfway through giving money away.

  3. 03Approach

    Block at the edge, then treat the incident as evidence rather than noise to absorb and move on from.

  4. 04Technology

    Firewall rules at the edge, log evidence packaged for escalation, then a prioritised remediation plan.

  5. 05Result

    The source was escalated to its host, who notified their customer. All four platforms brought to one standard.

04/ 052026

STEPtember Points Engine

A rewards economy the client reconfigures mid-campaign, without a developer, a release, or a line of code.

A complete points, rewards and prize-entry engine for a mass-participation fitness campaign, built as a first-class module on top of the platform rather than as page-level customisation. Twenty-five reward triggers, all of them data rather than code branches.

Role
Architect and engineer
Scale
25 configurable triggers, ~2,600 lines across controller, model and admin
Impact
New triggers and milestones ship as a database row, not a deployment
  • PHP
  • MySQL
  • CodeIgniter
  • Webhook integration
  • Idempotent award logic
  • Admin CMS module
  1. 01Problem

    A campaign wanted a points and rewards economy it could run itself: profile completion, first donation, team joining, fundraising milestones, daily activity, per-dollar accrual.

  2. 02Challenge

    Webhooks retry and fire on state changes, so an award has to be safe to attempt repeatedly. And the front end cannot be trusted to say what somebody has earned.

  3. 03Approach

    Put the reward economy in the database. Twenty-five triggers as rows with a key, category, point value and enabled flag, all editable in admin.

  4. 04Technology

    A webhook receiver keyed by URL segment, an awarding engine with a three-mode frequency model, two custom tables including an append-only log, and a CMS module for the client.

  5. 05Result

    A new trigger is a row in admin and a URL pasted into the CMS. No code change, no release, no engineer.

05/ 052026

Payment Forensics

Four blank transactions in five days, three completely different root causes, and not one of them visible in the application code.

Payments cleared and raffle entries were valid, but no usable customer details reached the sale record. On a live campaign that means taking money from supporters nobody can then identify. Rebuilding each journey from server logs turned up three separate failures wearing the same symptom.

Role
Investigation lead
Scale
Three root causes behind one identical symptom
Impact
Each path separated, reproduced and explained, none of them Stripe
  • Stripe
  • Apple Pay
  • Server log analysis
  • iOS WKWebView
  • Payment intents
  1. 01Problem

    Four raffle transactions over five days recorded blank customer details. The money arrived, the entries were valid, and nobody knew who had paid.

  2. 02Challenge

    One symptom, and nothing in the application code that could produce it. It was not reproducible from the platform alone.

  3. 03Approach

    Treat it as forensics. Correlate the records against raw server logs, request timing, user-agent strings and gateway responses, and rule the gateway out early.

  4. 04Technology

    Log-level reconstruction of real user journeys across specific browsers, wallets and devices, including a blank user-agent that proved which records a cron had written.

  5. 05Result

    Three genuinely distinct root causes, each reproduced and explained rather than patched over.

07AI engineering

Production AI,built end to end.

The first years were spent on a legacy platform with no conventions and no assistant, which meant reading it until it made sense. That is where the judgement came from, and none of it has changed. What changed is how much fits into a week: ZOSA's mobile app caught up with two years of web work in about four months, still with one person on it.

Built in productionZOSA

Select a capability to see how it is built.

4 capabilities · one production system

Adopted across a teamFunraisin

At Funraisin, the harder half is getting a delivery team of fifteen to use it well.

The problem

Four regions, four habits, and whichever assistant each developer had picked up. All of them write textbook framework code, which on a bespoke platform is wrong in ways that survive a glance and fail review.

The pack

A versioned context pack, written and maintained in-house: an agent briefing read first, a directory map and core-versus-custom boundary, a table inventory so an agent verifies a table rather than inventing one, a helper signature catalogue so it reuses utilities instead of duplicating them, and one real payload file per webhook action. The manifest routes by task type and exists as much to say what not to read, because context budget is a real constraint.

The workflow

Four stages behind one command: question, build, review, rework. A human confirms the spec before code exists, the review returns a pass or fail with ranked findings, failures go back to build with the findings attached, and the standards underneath it are enforced rather than suggested. Cached query variants by default, cache keys always scoped by entity ID, and no AI output that is anything other than a draft for review.

The adoption

The same standards work for developers with full repository access and for those on pack-only access, which is what an offshore delivery model actually looks like. Everyone moved onto Claude Code and one way of working, with workshops on site in Indonesia across all four delivery pods and agent logs so the work stays auditable.

The balance

Judgement · velocity · control

01

The engineering came first.

The early years went on reading a legacy platform rather than generating against one: multi-tenant data models, donation and payment lifecycles, cron batches held inside gateway timeouts. That is what makes generated code safe to accept quickly. An assistant writes confident code against a framework that is not there, and you catch it because you know the codebase, not because you wrote a better prompt.

02

More output, same standard.

Subagent definitions, slash-command pipelines and a context pack that makes output platform-shaped by default. On ZOSA that is a React Native app catching two years of web work in four months, and 819 commits across 291 days alongside a full-time director role. Nothing ships that would not have been written the same way by hand. It just arrives sooner, and the ideas once shelved as too expensive now get built.

03

Autonomy, with a checkpoint.

Scheduled agent pipelines run outside work too: one researches leads and drafts B2B outreach, another assembles a daily brief on a market worth watching. Same shape in both. Gather on a schedule, filter with something cheap, summarise, and put a person at the point of no return. Approving an email does not send it, it schedules it into the recipient's local morning, which leaves a window to change your mind.

Scope of the claim

Built · contributed · proposed

Built

Production AI engineering

Three and a half years of shipped AI in a live consumer product: orchestration, retrieval, realtime voice, extraction and safety evaluation.

Built

AI ways of working

Context pack, coding standards, agent and workflow definitions, and enablement run on site with the delivery teams.

Contributed

AI product roadmap

Helped shape a twelve-feature roadmap with effort estimation and revenue framing. Delivery sits with the product function, and is not claimed here.

Proposed

AI engineering leadership

A business case to formalise AI ownership across four regions, with an honest ramp and a named successor as a precondition rather than an afterthought.

08The route here

Six years,four promotions,one codebase.

One company, two continents, graduate developer to Director. Every stage asked for something the last one had not. Running alongside it since 2023: a product with nobody else on it.

Employed - FunraisinFounder - ZOSABefore Funraisin2020 - present
  1. July 2023 - PresentParallel

    Founder & Sole Engineer

    ZOSA · Australia · remote

    An AI mental health companion on iOS, Android and web, built end to end alongside a full-time role: product, architecture, engineering, cryptography, payments and positioning. Most of that had to be learned on the way, which was rather the point.

    • 819 commits across 291 separate development days
    • Shipped through App Store and Google Play review, including the Android defect behind a Play rejection
    • Two independent real-time voice pipelines behind one interface, swappable by a config constant
    • Migrated live conversations to AES-256-GCM, a schema migration over data nobody can read
    Team
    1
    Outcome
    Live on three platforms, with thousands of conversations and paying repeat subscribers.
    Worth talking about
    A causal symptom graph from a 2017 psychiatry paper, using betweenness centrality to find which symptom holds the rest in place.
    • Python
    • FastAPI
    • React Native
    • React
    • Firestore
    • WebRTC
  2. Sept 2025 - Present

    Director of Technical Delivery (AU)

    Funraisin · Australia

    Project delivery for Australia, the largest region at roughly 80% of the business: a team of fifteen engineers, architecture and sign-off on high-risk builds, scoping for enterprise accounts, major escalations, and the standards the delivery teams build against.

    • Leads the AU delivery team, fifteen engineers in-region and offshore, working alongside the project managers who plan against those numbers
    • Authored the AI standards, context pack and review workflow now used across distributed teams
    • Ran on-site workshops with the offshore delivery teams in Indonesia
    • Led the response to an automated attack on a live national platform, then closed remediation across all four
    • Holds the senior tier of platform access: production database and SSH to client web servers
    • Contributed to a twelve-feature AI product roadmap with effort and revenue modelling
    Team
    15+
    Outcome
    Output quality stopped depending on which region or which developer picked up the work.
    Worth talking about
    Turning AI from individual experimentation into a governed team capability.
    • PHP
    • MySQL
    • CodeIgniter
    • Claude Code
    • Bitbucket
  3. Jan 2025 - Sept 2025

    Team Lead

    Funraisin · Australia

    A first people-leadership role, and the year it became clear that owning what a team ships is a different job from owning code.

    • Established code review and technical standards across in-region and offshore teams
    • Mentoring and career development across the delivery teams
    • Reached the senior tier of platform access
    Team
    10
    Outcome
    Eight months later, the same work at regional scope as Director.
    Worth talking about
    Getting one set of standards to hold across in-region and offshore teams at once: a people problem long before a technical one.
    • PHP
    • MySQL
    • JavaScript
  4. Late 2023 - Jan 2025

    Senior Developer

    Funraisin · Australia

    Where the question changed from how do you build this to what should be built. Architecture-level ownership of the awkward parts: donations and payments, the fundraiser data model, raffle mechanics at scale.

    • Payments across Stripe Elements, digital wallets and multi-account routing for multi-charity platforms
    • Raffle platforms for Camp Quality, draw mechanics reviewed against 50,000-entrant loads
    • Multi-state campaign work for Cancer Council, including the 7 Bridges Walk
    Outcome
    Promoted to Team Lead in January 2025.
    Worth talking about
    Multi-state campaign architecture where one page has to resolve to the right state entity, charity allocation and payment destination.
    • PHP
    • MySQL
    • Stripe
    • jQuery
    • Memcached
  5. Oct 2022 - Late 2023

    Developer - AU region

    Funraisin · Australia

    A move to the other side of the world, and a new team on arrival. New market, new clients, new compliance, same codebase.

    • Custom delivery across campaign builds, integrations and admin modules
    • Large-scale data analysis across the AU charity book
    Worth talking about
    Rebuilding working context from scratch in a new market, on a codebase already known inside out.
    • PHP
    • MySQL
    • JavaScript
    • Bootstrap
  6. Sept 2020 - Oct 2022

    Junior Developer - UK region

    Funraisin · United Kingdom

    A first role in a team, mostly spent reading a large legacy platform from the inside out. Far more enjoyable than that sentence suggests.

    • Learned a platform spanning ~50 admin modules, 275 routes and a parallel template tree
    • UK-region client delivery, including Gift Aid and Swiftaid tax reclaim flows
    Worth talking about
    Gift Aid and Swiftaid tax reclaim flows, where correct behaviour is defined by HMRC rather than by anybody in the building.
    • PHP
    • MySQL
    • jQuery
    • HTML
    • CSS
  7. Early 2020 - Sept 2020

    Freelance Web Developer

    Independent · United Kingdom · remote

    Six months building sites for small businesses and overseas clients, talking to owners directly. Where asking what somebody needs, rather than quoting for what they asked for, became a habit.

    • The first clients whose income depended on the code
    • A UK commercial vehicle business, with real operational traffic behind it
    • A traditional Chinese medicine clinic in Hong Kong, built bilingual in English and Chinese
    Team
    1
    Worth talking about
    Building for readers in a language nobody on the project spoke: the first time the work had to be designed around something impossible to check directly.
    • PHP
    • JavaScript
    • HTML
    • CSS
    • WordPress
  8. Late 2019 - Early 2020

    Ski Instructor

    Ski school · Japan

    A season teaching people to ski, most of them nervous and starting from nothing. The least technical job here and possibly the most useful: explain one thing clearly, then read their face to see whether it landed.

      Waypoints
      1. 2019Left Bristol with a BSc · a season teaching skiing in Japan
      2. 2020Freelance clients, then Funraisin as a graduate developer
      3. 2022Packed up the UK, moved to Australia
      4. 2023Senior Developer · ZOSA begins in July
      5. 2025Team Lead in January, Director in September
      6. 2026AI standards across four regions · ZOSA live on three platforms
      09Get in touch

      Let's talk.

      Six years ago this was one graduate reading a legacy platform from the inside, having never led anybody. The through-line since has not changed: find the problem underneath the reported one, and be understood by whoever has to act on it.

      What makes a role worth taking: AI at the centre of it, and a team worth building. Past that, deliberately open: the best work so far never arrived with the job title anyone would have predicted, so the problem matters more than what it is called.

      If that is roughly the shape of what you are hiring for, say hello. If you would rather think out loud about a delivery, architecture or AI problem with no job attached, that works too. This reaches me directly.

      Or reach me on LinkedIn, whichever is easier.