I write small tools for specific problems.

Most of what is on this page started as a nuisance: a spreadsheet that couldn't tell me where a lens was, a transcript nobody could read, a homelab I couldn't see at a glance. Each one turned into a small tool, and most of them into an article about how it was designed and why.

The problems sit where my work overlaps: post-production, cybersecurity, interface design, and the practical business of running a studio. I solve them in the browser, in Python, on a Raspberry Pi, and increasingly with AI agents doing a lot of the typing.

Software & Hardware

Things I've built.

Every card links to the write-up: the problem, the design decisions, and what I would change.

Production tools

Utilities for the edit suite, the set and the classroom.

Private by design

Personal tools that keep the data with the person it belongs to.

Design, imagery and 3D

Layout systems, satellite imagery, and a studio built by an agent.

Studio, hardware and homelab

Displays, racks and shelves: the physical side of keeping things running and findable.

Where it started

Visual Basic, fintech, Y2K.

I started with Visual Basic, and studied some computer science at university before being thrown into workflow work in fintech, right in time for the Y2K bug. It was a crash course in how much a system rests on assumptions nobody wrote down, and how much work it takes to find them before they find you.

Post-production took over after that, but the habit stayed. Python became what I reach for when a folder of files, an export or an API needs sorting out, and the instinct for where a process will break turned out to be useful in a grading suite too.

How I build now

Working with agents.

These days much of the implementation is done with AI coding agents. I write the brief, set the constraints, decide the architecture and review what comes back. The part that still takes the time is the part it always did: defining the problem clearly enough that the tool has a reason to exist, and knowing when the output is wrong.

This site is built that way, including the isometric studio on the home page: modelled, lit and rendered in Blender by an agent driving it through MCP, then wired into the page so every object links to a section.

Where the problems come from

Four overlapping fields.

Post-production

Twenty-five years of grading, finishing and delivery is where most of the problems come from: scopes for teaching, transcripts an editor can actually read, project structures that survive a handover.

Security

A Certificate IV in Cyber Security from RMIT and the ISC2 Certified in Cybersecurity credential sit underneath the way I build: private data models, local-first storage, and a segmented homelab where the theory has to hold up.

Design

Interaction design training through the Interaction Design Foundation shapes every tool here. Each one starts from what the person using it needs to see and do, not from what is easy to code.

Practical things

Some problems are physical: a kiosk in a 3D-printed frame, a rack display that works like a miniature NOC, a map of which drawer the lens is actually in.

What's next

Live events and installations.

I'm now moving into technology for live events and installations: TouchDesigner for real-time visuals, Dante for audio over the network, and Q-SYS for control and processing. It is the same instinct pointed at a room instead of a timeline: signal flow, networks, and systems that have to work first time, in front of an audience.

A small problem that won't go away?

If a tool is too heavy, too vague, or missing entirely, describe the friction. I'll tell you whether it is worth building.

Get in touch