Director of Technical Delivery & AI Engineer

Fifteen engineers.Four delivery pods.One product built alone.

I run bespoke client delivery for the Australian region at Funraisin, an agency built around its own fundraising platform. Alongside it I built ZOSA, an AI product now live on iOS, Android and web, on my own. I still ship to it most weeks.

Based
Australia
Timezone
AEST · UTC+10
Status
In role. Open to conversations.

A fundraising platform used by nearly 1000 global charities, including UNICEF, WWF and Greenpeace.

Fifteen engineers building bespoke work on top of it.

And no quiet window to deploy into.

02Introduction

I am a technical leader who never stopped building. Fifteen engineers, four delivery pods, a platform used by close to a thousand charities, and a product of my own shipped alone.

The role is Director of Technical Delivery for the Australian region at Funraisin. I own the architecture decisions, the high-risk builds, the security response, and the standards everyone builds against. Funraisin is an agency built around its own product: we ship the platform and keep improving it, charities customise campaigns on top, and my teams deliver that bespoke work. Launch dates are usually announced before the work is scoped, which tells you most of what you need to know about the job.

The title says Australia. In practice I work with product engineering on shared standards, support the US region, and run the AI enablement four regions build against. On any given day I am translating between offshore developers, project managers, senior leadership and charity fundraisers who have never read a technical document in their lives. Being understood by all of them is most of the job.

I joined in September 2020 as a junior developer in the UK and spent the first year not really understanding the platform. Four promotions and one continent later I hold the Director title, on the same codebase. It never got simpler: around fifty admin modules, 275 routes, a data layer somebody wrote by hand, and campaigns where an hour of downtime is counted in lost donations. I still think the most useful thing I do is read something carefully and ask the question everyone assumed had already been asked.

Then there is ZOSA. Suicide has taken people out of my life more than once: friends, and friends of friends. What stays with me each time is how little the people around them knew, myself included. ZOSA is not an answer to that. I would not claim a piece of software prevents anything, and I am wary of anyone who does. It is meant to help in the gap: even with a therapist you get one hour a week, and nobody is with you for the other 167. In early 2023 I started building something for those hours.

It is now live on iOS, Android and web. 819 commits across 291 separate days, every one of them outside work. It is where my AI engineering came from, and it is why I trust the standards I now set for other teams. I have had to live inside them on my own, at midnight, with nobody to review the pull request.

Measured

Two careers, tagged separately

Funraisin
0+
Engineers & PMs led
Four cross-functional delivery pods plus an in-region team
Funraisin
0
Promotions in six years
Junior developer to Director of Technical Delivery, across two continents
Funraisin
0
Regions supported
AU owned outright; UK, US and NZ supported technically
ZOSA
0
Commits, solo product
Across two repositories and still climbing, every one hand-tagged under a strict version scheme
ZOSA
0
Distinct development days
Roughly one day in three since March 2024, with no month missed to date
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%
03How I think
  1. 01Judgement

    Record the reasoning, not just the result.

    A decision without its rationale becomes folklore within a year, and the next engineer either repeats the mistake it avoided or removes the safeguard it added. I write the why next to the what, in the code, at the point the call is made.

  2. 02Product thinking

    Lead with the problem, not the technology.

    I rewrote two years of product positioning because opening with the technology invited the objection before the argument had been made. The same applies internally: a proposal that opens with the solution gets a debate about the solution.

  3. 03Security

    Enforce it where it cannot be bypassed.

    Client-side limits are user experience. Server-side limits are control. Rate limits, quotas, tier caps and tenant scoping are all checked again somewhere the client cannot reach, because on a multi-tenant platform the cost of getting that wrong is somebody else's data.

  4. 04Cost discipline

    Establish the cheap signal first.

    Before ZOSA calls a model it computes what plain Python can compute in under a millisecond. Inference is reserved for the judgement that genuinely requires it. The general form: understand what the cheap measurement tells you before you pay for the expensive one.

  5. 05Standards

    Generated code is a draft, never a deploy.

    The first rule in the standards I wrote for the delivery teams. Generation is fast and confident; review is what makes it safe. The workflow has human checkpoints because the failure mode is plausible code that breaks against constraints the model never saw.

  6. 06Leverage

    Automate what should never have been manual.

    An integration that required a find-and-replace across the codebase every year now reads the year from the database. I build tooling so the team spends its attention on the problems that actually need it, which is also the honest reason I built the AI workflow.

04How I lead

Engineering ishalf the job.

The other half is getting the right things built, by people in four time zones, against campaign dates that do not move.

Idea to iteration
  1. Idea

    A charity wants something the licensed platform does not do yet. Or a defect worth taking seriously.

  2. Discovery

    Scoping calls, effort modelling, and deciding what belongs in bespoke work versus what the core platform should absorb.

  3. Architecture

    Design authority and final technical sign-off on approach before any work starts.

  4. Build

    Four cross-functional pods, standards-led, with the reference material they build from written and maintained.

  5. Review

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

  6. Delivery

    Release sequencing against live campaign windows where there is no quiet period to deploy into.

  7. Iteration

    Client reporting in plain English, remediation plans, and the next thing the incident taught us.

How I solve problems

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

  1. 01

    Problem

    What actually needs solving?

    The stated problem is usually a symptom. A batch job timing out was really a query that fetched rows it had already processed. Before anything gets built I want the sentence that describes the failure, not the ticket that describes the annoyance.

  2. 02

    Challenge

    Why is it hard?

    Find the constraint that will decide the design, and be honest about whether it is technical, organisational or commercial. Tiered repository access across an offshore team is not a technical constraint, but it determined the entire shape of the AI standards.

  3. 03

    Approach

    What is the smallest thing that proves it?

    Prove the risky part first and keep it cheap. On a live campaign platform there is no maintenance window, so the sequencing question - what can be staged, what has to be atomic - is part of the design rather than something handed to release management afterwards.

  4. 04

    Technology

    What gets built, and what does not?

    Move what varies into data. Choose boring where boring is sufficient. Two dimensions of the ZOSA style profile were designed and then deliberately removed because they could not be measured reliably - knowing what not to build is the same skill as knowing what to.

  5. 05

    Result

    What changed?

    Instrument it so the next regression names itself. Per-pass debug counters, agent logs, error analysis that runs over its own production logs. If a fix cannot be verified from outside your own head, it is not finished.

Who I write for

Most delivery failures I have seen were communication failures wearing a technical costume.

The same decision has to reach four audiences who need it in four different forms. Getting that wrong is not a soft failure. It is how a project quietly goes off the rails while everyone believes they agreed.

  1. 01

    Offshore engineers

    Technical specs, reference material and the standards they build against, written to be read in a second language and without me in the room.

    Fifteen people across four pods, several time zones away. Anything ambiguous costs a full day of round trip.

  2. 02

    Project managers

    Scope, sequencing and honest effort estimates, including which parts are risky and why the risky ones go first.

    They commit to dates on my numbers. An optimistic estimate is not a kindness.

  3. 03

    Charity clients

    Plain-English incident and change reports. What happened, what it means for their campaign, what I did about it, what happens next.

    Fundraising leads are not engineers. If they cannot explain it upward themselves, I have not finished writing it.

  4. 04

    Senior leadership

    Commercially framed proposals: effort modelled against revenue impact, resourcing stated, trade-offs named out loud.

    A technical argument without a commercial one is a preference. Budget decisions need both halves.

Corrections

Four times I was wrong about something that mattered.

  1. 01

    I fixed the wrong thing first.

    A batch job was timing out, so I rewrote the queries and the timeouts stopped. It took a second run to notice the job had been reprocessing the same records every time, which was the actual defect and had been there the whole time. I had treated the symptom because the symptom was the thing being reported.

  2. 02

    I shipped a build a reviewer could not use.

    Google Play rejected version four. Gesture Handler buttons are inert inside native modals on Android, so a reviewer literally could not tap through a flow. I had tested the path on iOS and assumed. The fix took an hour; finding it took considerably longer, and it is now a project-wide component convention so nobody repeats it.

  3. 03

    I led with the technology for two years.

    ZOSA's positioning opened with AI, which invited every objection before I had earned the right to answer any of them. It took outside feedback and a fairly uncomfortable session to accept that two years of my own copy was working against me. I rewrote all of it.

  4. 04

    I measured two things that could not be measured.

    The adaptive style profile originally had eleven dimensions. Two of them, pace and challenge, are not reliably recoverable from text, and I had built them anyway because they sounded right. I removed them. Knowing what not to measure turned out to be the part I had skipped.

The other half

Technical strategy

Standards, tooling and direction across four regions, including arguing for a shared service layer so twelve features are built once rather than integrated twelve times.

Reach beyond the region

The title says AU, but the work does not stop there. Shared standards with product engineering, technical support for the US region, and the AI enablement used by delivery teams in all four.

Architecture authority

Final sign-off on approach for complex and high-risk builds, before work starts, not at review.

Distributed team leadership

Four offshore delivery pods plus an in-region team. Per-pod sessions instead of one broadcast all-hands, so each pod's context and blockers get real time.

Mentoring & careers

I ask developers where they want their careers to go and shape the work around the answer. Assigning tickets and calling it development is the thing this replaces.

Psychological safety

I run per-pod sessions where the first thing I ask for is what is not working, and I say out loud that anything raised there stays there. It only counts once someone tests that and finds it holds.

Scoping & estimation

Effort modelling and delivery sequencing for enterprise accounts, including the trade-off between headcount and delivery date.

Escalation ownership

Technical incidents and client-facing escalations both land here, including the ones that arrive mid-campaign.

Stakeholder range

Technical specs for engineers, plain-English incident reports for charity clients, and commercially framed proposals with effort and revenue modelling for the senior leadership team.

Risk & security posture

Review, incident response, remediation planning and the client communication that goes with all three.

Production access

The senior tier of platform access: direct production database access via phpMyAdmin and SSH to client web servers, for diagnostics, data verification and operational work on live platforms. A trust and access level, deliberately restricted, sitting above the tier granted to delivery developers.

05The technology

One system, six domains.

Select a domain to see what sits inside it, and what it connects to.

COREFRONTENDBACKENDAIDATAPLATFORM
Domain

Core

Two stacks, held at architecture level: an agency's own fundraising platform in legacy PHP, which my teams customise for each charity, and a Python AI product I own end to end.

Technologies
  • PHP 7.4 / 8.x
  • Python 3.12
  • TypeScript
  • SQL
All domains
06Selected work

Five thingsworth explaining.

One product I build alone, and four pieces of client delivery on a platform I did not. Each is written up the same way, because the frame matters more than the outcome: what was wrong, why it was hard, and what actually changed.

Platform clients

Accounts across the platform's client base. The projects below are the ones with specific, describable engineering behind them.

UNICEF
WWF
Greenpeace
Cancer Research UK
Mental Health UK
Alzheimer's Association
Race for the Kids
The Push-Up Challenge
Cancer Council
Camp Quality
01/ 052023 - present, in active development
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

A production AI system on iOS, Android and web: multi-provider orchestration, hybrid memory retrieval and real-time voice, architected and built by one person.

Six model providers behind one capability-tiered interface. A three-layer memory system with dynamic budgets and a relevance floor. Two independent real-time voice pipelines behind an identical contract. An intelligence layer that runs entirely off the response path. 819 commits across 291 separate days, still shipped to most weeks, alongside a full-time director-level role.

Role
Architect, sole engineer, product owner
Scale
120 endpoints, 6 providers, 14 models, 3 platforms
Impact
Live on the App Store, Google Play and web, with paying repeat subscribers
  • Python 3.12
  • FastAPI
  • LLM orchestration
  • Vector retrieval
  • WebRTC realtime
  • React Native
  • Firestore
  • AES-256-GCM
  1. 01Problem

    Suicide has taken people out of my life more than once: friends, and friends of friends. Each time, nobody close to them knew how bad it had got. Software does not fix that and I would not claim it does. It can occupy 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-window management and cost control at once, on a consumer product where a single voice session can burn real money in real time.

  3. 03Approach

    Treat the model as one component in a system, not as the system. Design the layers around it: what gets retrieved, what gets summarised, what never reaches it, and what happens when it is wrong.

  4. 04Technology

    A 120-endpoint async FastAPI service where the entire intelligence layer runs as background tasks. Six providers behind capability tiers resolved from environment variables. Hybrid retrieval over Firestore native vector search with a FAISS fallback.

  5. 05Result

    A live product on three platforms with paying repeat subscribers, still shipped to most weeks, on an AI architecture that came out of primary research.

02/ 052025 - 2026

AI Ways of Working

Context engineering that turned AI from an individual productivity hack into a governed team capability.

Developers across four regions were using AI assistants that produced generic, framework-default code - wrong for a bespoke legacy platform with custom DB helpers, custom caching and hard multi-tenant constraints. The output looked plausible and failed review. I wrote the context pack, the standards and the workflow that fixed it.

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

    AI assistants generate framework-default code. On a bespoke CodeIgniter platform with a custom DB helper layer, custom caching and multi-tenant isolation rules, framework-default is wrong in ways that pass a glance and fail review.

  2. 02Challenge

    The teams are distributed across four regions with tiered repository access - some developers cannot see core files at all. Any standard that only works with full repo access solves the problem 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, and route context by task type because context budget is a real constraint.

  4. 04Technology

    A versioned reference pack - agent briefing, schema and table inventory, helper signature catalogue, real webhook payload files, a curated snippet library - plus a four-stage build-and-review pipeline with human checkpoints.

  5. 05Result

    AI-assisted work is now reviewed, architecture-conformant and auditable, with the same standards working for developers with and without core file visibility.

03/ 052026

Attack Response & Remediation

An automated attack on a live national fundraising campaign, and the four-platform hardening that followed it.

Very high volume driven through public forms from a single source, against a platform running a live campaign where downtime is measured in lost donations. Coordinated blocking at the edge, traced and escalated the source with evidence, then ran a full security review and closed out remediation across all four platforms.

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 against a live national campaign platform, driving very high volume through public forms from a single source, during an active event window with no quiet period to deploy into.

  2. 02Challenge

    Stopping the traffic without stopping legitimate donations, on a platform where the cost of a false positive is a supporter who gives up mid-donation.

  3. 03Approach

    Block at the edge before it reaches the application, then treat the incident as evidence, not as noise to be absorbed.

  4. 04Technology

    Web application firewall rules at the edge, full server log evidence packaged for third-party escalation, then a prioritised remediation plan across custom platform code and core system files.

  5. 05Result

    The source was formally escalated to its hosting provider, who identified and notified their customer. All four platforms were brought to a consistent standard and a legacy administrative surface was retired.

04/ 052026

Batch Performance Rework

Eight query passes, one 504, and a reprocessing bug that only appeared on the second run.

A batch archival job was timing out on large datasets. Rewriting the queries fixed the timeout; the more interesting problem was the defect underneath it, where the same records were being reprocessed on every run.

Role
Engineer
Scale
Client datasets in the hundreds of thousands of rows
Impact
504s eliminated; future regressions attributable to a specific pass
  • MySQL
  • PHP
  • Query optimisation
  • Idempotent batch design
  1. 01Problem

    A batch archival cron was hitting gateway timeouts on client datasets running to hundreds of thousands of rows per entity.

  2. 02Challenge

    The obvious fix - paginate with offsets - needs state, and state in a cron job is another thing that can drift out of sync with reality.

  3. 03Approach

    Make each pass fetch only the rows that still need work, so the job self-advances without tracking where it got to.

  4. 04Technology

    All eight SELECT passes rewritten with NOT EXISTS / EXISTS guards and a configurable batch size cap per pass.

  5. 05Result

    Timeouts gone, and the defect underneath them root-caused instead of patched over.

05/ 052026

Multi-Country CRM Refactor

One campaign, four national platforms, one codebase - and an annual find-and-replace that no longer exists.

An Iterable integration that assumed a single country, carried a hardcoded event-year key requiring a codebase-wide find-and-replace every year, and had no deduplication for one-off communications. Rebuilt so that adding a country needs a key, not a code change.

Role
Architect and engineer
Scale
Four national platforms from a single codebase
Impact
Eliminated a recurring annual maintenance task and a whole class of copy-paste error
  • PHP
  • MySQL
  • Iterable
  • Timezone resolution
  • Configuration-driven design
  1. 01Problem

    The Push-Up Challenge runs in four countries from one codebase. The CRM integration assumed one of them.

  2. 02Challenge

    Every year the event-year key had to be found and replaced across the codebase by hand - a scheduled opportunity to break a live integration, repeated annually.

  3. 03Approach

    Move everything that varies into data. If it changes per country or per year, it belongs in the event record, not in the source.

  4. 04Technology

    Country read from the event record and routed to the correct Iterable account and API key automatically. Event-year key derived from the event code in the database. A three-tier timezone resolution chain and reliable one-off deduplication.

  5. 05Result

    Adding a new country needs a key, not an engineer. The annual manual migration is gone entirely.

07One system, all the way down
ZOSAsolo build, in active development

Every layer ofone system.

That was ZOSA from the outside. This is the same product from the inside, one layer at a time. It is the only system on this page I own from the pixel to the dyno, which makes it the only one I can describe honestly at every level.

00User
  1. 00

    User

    Someone at 11pm with nobody to talk to. Every decision below this line is answerable to them.

    Decision
    Anonymous use with a hard message cap before any account is asked for, then migration that carries the anonymous session across. Value first, identity second.
    Challenge
    The people this is for are, by definition, the least likely to fill in a signup form about how they are feeling.
    • iOS
    • Android
    • Web
  2. 01

    Clients

    Three surfaces, one data model, one encryption scheme.

    Decision
    Bare workflow with ios/ and android/ committed, so native project files stay under direct control, and over-the-air JS updates for everything that does not need a store round trip.
    Challenge
    Gesture Handler buttons are inert inside native modals on Android. It cost a Play Store rejection, and the fix became a project-wide component convention so it cannot regress.
    • React Native 0.81
    • Expo SDK 54
    • React 19
    • Expo Router
  3. 02

    Encryption

    The privacy claim, made architecturally true rather than promised.

    Decision
    Encrypt on the device, identically on React Native and web, so an account written on one platform decrypts on the other and the operator holds no key.
    Challenge
    Migrating live conversations from unencrypted v1 to v2 AES-GCM - a schema migration over data nobody, including me, is able to read.
    • AES-256-GCM
    • PBKDF2 100k
    • BIP39
    • Biometric unlock
  4. 03

    API

    120 endpoints. Async throughout, and boring on purpose.

    Decision
    Incremental decomposition of a monolith into 15 domain route modules behind a shared bridge module, so the extraction never required a big-bang rewrite.
    Challenge
    Every synchronous Firestore call had to be wrapped in asyncio.to_thread - the database SDK will happily block the event loop for the whole process.
    • FastAPI
    • Pydantic v2
    • Uvicorn
    • Firebase ID tokens
  5. 04

    Intelligence

    Six providers, fourteen models, addressed by capability rather than by name.

    Decision
    Every call site asks for a tier - fast, smart, vision, embedding - and each tier resolves per provider from an environment variable. The product can change vendor without a deploy.
    Challenge
    Absorbing three incompatible SDKs behind one interface: system prompt placement, token semantics, JSON mode and streaming event shapes all differ.
    • OpenAI
    • Anthropic
    • Google
    • Deepgram
    • Cartesia
  6. 05

    Memory & retrieval

    Three competing layers with separate, dynamic budgets.

    Decision
    Past strengths are retrieved outside vector search entirely, because someone opening with a problem is by definition not semantically similar to a past win.
    Challenge
    find_nearest always returns its N nearest vectors however far away they are, so a new topic returned confidently irrelevant memories until relevance hits had to clear an explicit distance floor.
    • Firestore vector search
    • FAISS fallback
    • Soft compaction
  7. 06

    Data

    23+ Firestore collections, indexed, chunked and versioned.

    Decision
    Subcollection chunking for encrypted transcripts, transparent to every caller, because a long conversation exceeds the 1MB per-document limit.
    Challenge
    Keeping derived data - memories, summaries - encrypted at rest too, so nothing internal quietly reconstructs what the client-side encryption was meant to protect.
    • Firestore
    • Composite indexes
    • Atomic increments
    • Real-time listeners
  8. 07

    Commerce

    Three payment rails, because platform policy leaves no choice.

    Decision
    One Firestore document is the single source of truth for prices and product IDs across all three clients; the platform then routes by Platform.OS.
    Challenge
    Server notifications from Apple and Google mean different things - a cancellation keeps access until expiry, a revocation removes it immediately - and both have to map back to the right user.
    • Stripe
    • Apple StoreKit
    • Google Play Billing
  9. 08

    Operations

    Scheduled work, safety screening and error triage, all off the response path.

    Decision
    The entire intelligence layer runs as background tasks. Memory processing, style extraction, graph merging, safety screening - the user never waits for any of it.
    Challenge
    Timezone-safe scheduling: duplicate daily jobs an hour apart so the correct local hour survives daylight saving, with an idempotent guard so the wrong one exits immediately.
    • Heroku Scheduler
    • Background tasks
    • SendGrid
    • Playwright
08AI engineering

Most of the work is decidingwhat not to hand a model.

You have seen the engineering already. What it taught me is the part that transfers: the interesting question is never what a model can generate, it is what you put in front of it, what you refuse to give it, and how you find out when it was wrong. The rest of this chapter is the second half of that job, which is getting fifteen other people to build against those answers.

Built in productionZOSA

Select a capability. The field reorganises around it.

4 clusters · one system

Adopted across a teamFunraisin

The other half is getting a team to use it well.

The problem

Developers across four regions were using AI assistants that produced framework-default code. On a bespoke platform with a custom data layer, custom caching and hard multi-tenant rules, framework-default is wrong in ways that pass a glance and fail review.

The pack

A versioned reference pack I wrote and maintain: an agent briefing, a schema and table inventory, a helper signature catalogue, real webhook payload files, and a curated snippet library. Plus a manifest designed as much to say what not to read as what to read.

The workflow

A four-stage pipeline with human checkpoints. Question, build, review, rework. The review stage returns PASS or FAIL with ranked security and efficiency findings, and failures go back to build with the findings attached.

The adoption

On-site workshops across all four delivery pods in Indonesia, plus a dedicated acceleration session. Agent logs so AI-assisted work is recorded and auditable. Standards that work equally for developers with full repository access and those with none.

Positions
01

Grounding beats prompting.

A generic assistant on a bespoke platform writes plausible code against a framework that is not there. The fix was never a better prompt - it was a catalogue of the tables, helpers and payloads that actually exist, and a manifest that tells the agent what not to read.

02

Measure what a regex can measure.

Quantifier density, type-token ratio, repetition, hedging - all computed in under a millisecond of plain Python before any inference happens. Spend tokens only on the part that genuinely needs judgement.

03

Autonomy needs an undo.

The outreach agent researches leads and drafts emails, and a human approves every one. Approving does not send - it schedules into the recipient's local morning, which is both better for open rates and what makes a real undo window possible.

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, structured extraction and safety evaluation.

Built

AI ways of working

Context pack, coding standards, agent and workflow definitions, and on-site enablement across four delivery pods.

Contributed

AI product roadmap

Contributed to shaping a twelve-feature roadmap spanning Q4 FY26 to Q4 FY27, including effort estimation, acceleration modelling and revenue impact framing. Delivery sits with the product function.

Proposed

AI engineering leadership

A business case to formalise AI ownership across four regions - with a shared service layer strategy, an honest ramp, stated resourcing, and a named successor as a precondition rather than an afterthought.

09Experience

Six years,four promotions.

One company, two continents, junior developer to Director of Technical Delivery. Running alongside it since 2023: a product of my own, which is where the AI engineering came from.

Employed - FunraisinFounder - ZOSA2020 - present
  1. 2023 - PresentParallel

    Founder & Sole Engineer

    ZOSA · Australia · remote

    An AI mental health companion on iOS, Android and web, architected and built end to end by one person alongside a full-time role, and still shipped to most weeks. Product, architecture, engineering, cryptography, payments, pricing, positioning and the outreach pipeline that sells it.

    • 819 commits across 291 separate development days and counting, with no month missed since March 2024
    • Shipped through App Store and Google Play review, including diagnosing and fixing the Android defect behind a Play rejection
    • Built two independent real-time voice pipelines behind one identical interface, swappable by a single config constant
    • Migrated live user conversations to AES-256-GCM - a schema migration over data the operator cannot read
    Team
    1
    Outcome
    Live on three platforms with paying repeat subscribers, and still in active development.
    Worth talking about
    A causal symptom graph derived directly from a 2017 psychiatry paper, with betweenness centrality used to identify which single symptom is holding the rest in place.
    • Python
    • FastAPI
    • React Native
    • React
    • Firestore
    • WebRTC
  2. Sept 2025 - Present

    Director of Technical Delivery (AU)

    Funraisin · Australia

    Funraisin is an agency built around its own fundraising platform: we ship and continuously improve the product, and charities build campaigns customised to them on top of it. My teams deliver that bespoke work. I own technical delivery for the Australian region: architecture and sign-off on high-risk builds, scoping and estimation for enterprise accounts, major escalations, security posture for custom platform code, and the standards a distributed team of fifteen builds against. The role also reaches well outside the region, into product engineering, the US team and AI enablement across all four regions.

    • Lead 15+ engineers and project managers across four offshore delivery pods, plus an in-region AU development team
    • Authored the AI development standards, context pack and four-stage build-and-review workflow now used across distributed teams
    • Ran on-site workshops and AI acceleration sessions across all four delivery pods in Indonesia
    • Led the response to an automated attack on a live national platform, then closed remediation across all four national platforms
    • Hold the senior tier of platform access - production database access via phpMyAdmin and SSH to client web servers, for diagnostics and operational work on live platforms
    • Contributed to a twelve-feature AI product roadmap with effort estimation, acceleration modelling and revenue impact framing
    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, with grounding constraints that stop assistants inventing helpers, tables and file paths.
    • PHP
    • MySQL
    • CodeIgniter
    • Claude Code
    • Bitbucket
  3. Jan 2025 - Sept 2025

    Team Lead

    Funraisin · Australia

    First people-leadership role: technical direction and review across the AU delivery work, mentoring, and the move from owning code to owning what the team ships.

    • Established code review and technical standards across the in-region and offshore teams
    • Technical mentoring and career development for developers across the delivery pods
    • Reached the senior tier of platform access - production database access and SSH to client web servers
    Team
    [CONFIRM]
    Outcome
    Eight months later, the same work at regional scope as Director.
    Worth talking about
    [CONFIRM - the project that defined this period]
    • PHP
    • MySQL
    • JavaScript
  4. Late 2023 - Jan 2025

    Senior Developer

    Funraisin · Australia

    Architecture-level ownership of complex platform areas: donations and payments, the fundraiser and team data model, raffle and ballot mechanics at scale, and CRM integration design.

    • Payments engineering across Stripe Elements, digital wallets and multi-Stripe-account routing for multi-charity platforms
    • Raffle platforms for Camp Quality, with draw mechanics reviewed against 50,000-entrant loads
    • Multi-state campaign work for Cancer Council, including the 7 Bridges Walk event platform
    Outcome
    [CONFIRM - measurable outcome, if there is one worth publishing]
    Worth talking about
    Multi-state, multi-charity campaign architecture for a federated national charity, where one campaign page has to resolve to the correct state entity, charity allocation and payment destination.
    • PHP
    • MySQL
    • Stripe
    • jQuery
    • Memcached
  5. Oct 2022 - Late 2023

    Developer - AU region

    Funraisin · Australia

    Relocated from the UK to Australia and moved to the AU team. Custom client delivery across campaign builds, integrations and admin modules on the multi-tenant platform.

    • Moved regions and rebuilt working context in a new market with different clients, compliance and campaign patterns
    • Custom delivery across the AU charity book, including large-scale data analysis work
    Worth talking about
    [CONFIRM - the project that defined this period]
    • PHP
    • MySQL
    • JavaScript
    • Bootstrap
  6. Sept 2020 - Oct 2022

    Junior Developer - UK region

    Funraisin · United Kingdom

    Where it started. Learning a large legacy platform from the inside: a bespoke DB helper layer, a custom caching model, per-client theming, and multi-tenant isolation as a hard requirement rather than a nice-to-have.

    • Built working knowledge of a platform spanning ~50 admin modules, 275 routes and a parallel desktop/mobile template tree
    • UK-region client delivery, including Gift Aid and Swiftaid tax reclaim flows
    Worth talking about
    [CONFIRM - the project that defined this period]
    • PHP
    • MySQL
    • jQuery
    • HTML
    • CSS
Waypoints
  1. 2020Joined as a junior developer, UK
  2. 2022Relocated UK → Australia
  3. 2023Senior Developer · ZOSA begins
  4. 2024First ZOSA commit - 1 March
  5. 2025Team Lead in January, Director in September
  6. 2026AI standards across four regions · ZOSA still shipping
10Get in touch

Let's talk.

Six years ago I was learning a legacy platform from the inside and had never led anyone. The through-line since then has been the same in both halves of the work: find the problem underneath the reported one, write it down so the next person does not have to rediscover it, and be understood by whoever has to act on it. There is still no quiet window to deploy into. I have stopped waiting for one.

What I am looking for next: a new challenge, AI focused. Beyond that I am deliberately open. The most interesting work I have done did not arrive with the job title I would have predicted, so I would rather hear what the problem is than filter on a role name.

If that is roughly the shape of what you are hiring for, or if you want to talk through a delivery, architecture or AI problem with no job attached to it, this reaches me directly. I read everything that comes through here.

Or email bcwreford@gmail.com.