Projects

Pipelines I built and still run

Every project below is in production or has been. Each one names what it proves, what it cost me to learn, and where the boundaries are, including the parts that did not work. No concepts, no tutorials, no side projects that ran once and died.

In production Flagship

AroFlo data platform

Architect · Executor · Orchestrator

The finance platform I designed, built and run. It pulls a job-management system, accounting, HR and time-tracking into one governed warehouse that leadership's reporting reads from, and, more importantly, it is built to catch its own mistakes. Two independent pipelines load the same source into two databases so they can be checked against each other.

  • 15 data zones loaded in parallel
  • ~99% fewer records per run once seeded
  • 2 pipelines cross-checking each other
  • n8n
  • Python
  • SQL Server
  • Power BI
The build in depth
In production

Gearbox Vehicles, Plant & Equipment Report

Investigated, built and validated against production

One row per vehicle, plant item and piece of equipment: what it is, when it was last safety-checked, by whom, and its latest odometer and hour readings. It joins an API to a spreadsheet export because the readings are write-only and cannot be pulled from the API at all. The extract it replaced had been reading one page of nine.

  • 92 assets in one register, refreshed daily
  • 12.5% was all the previous extract could see
  • 13mth staleness caught before it shipped
  • n8n
  • SharePoint
  • Power BI
The build in depth
Maintained

Scope 1 & 2 emissions reporting

Automated carbon reporting

One extraction pattern, built for a clean supplier and proven against a much messier one, a folder mixing invoices, credit notes and purchase orders together. Different regulatory domain to finance, same discipline: the incremental version that shipped first would have quietly overwritten three years of invoice history, caught by a test written to force that exact failure before it ever touched production.

  • 120→112 PDFs classified, only the real invoices parsed
  • 13→2 rows the first version would have left standing
  • 4 invoice layouts handled in one mixed folder
  • n8n
  • SharePoint
  • Power BI
The build in depth
In production

Governed semantic layer

The layer between the warehouse and the report

Power BI does not point at raw tables. It reads a typed SQL view layer with a read-only login, so business logic lives in one place and a report cannot silently invent its own definition of a number. Seventy tables and a hundred and ninety-four measures in one model, with row-level security.

  • 70 tables in one governed model
  • 194 measures, row-level security
  • SQL Server
  • Power BI

Write-up in progress

You are on it

This website

Static site, own deployment pipeline

Hand-written HTML and CSS with no framework, assembled from partials by a small build script, deployed by pushing to a public repository that the host pulls automatically. A private build repo holds the source; only what should be public ever reaches the public one. Boring on purpose: it costs nothing to run and cannot break at 2am.

  • Python
  • Git

Write-up in progress

Get in touch

I am happy to walk through any of these builds in depth: the architecture, the decisions behind it, or the parts that failed and what I changed afterwards.

Adelaide, South Australia · ACST (UTC+9:30)