Systems built to take work off the desk

The reporting layer behind my events business. One screen answers what most event organisers work out afterwards in a spreadsheet, if at all: revenue against supplier costs and sponsor income, how many of the people in the room had been before, and for each marketing campaign, what it cost set against what it actually brought in.

It was originally written the obvious way — pull every paid registration into the application and add it up in code, on every single request. That works until it doesn't, and it gets slower precisely as the business gets busier. So the arithmetic moved into the database, where the data already is, and the application receives finished totals rather than raw rows.

An inventory and fulfilment app — products, variants, stock levels, orders, picking, and the reporting over it — built against a proper relational schema rather than a spreadsheet pretending to be one.

Then I costed running it in-house against paying an outsourced fulfilment partner, and the outsourced option won at our launch volume. So we use theirs. The analysis produced a specific number for when that flips — sustained monthly order volume roughly double our launch projection — which is written down as the trigger to revisit, rather than left as a vague someday.

No subscription app on our store platform supports a single South African payment gateway. Rather than change either, I built the bridge: it holds the customer's authorised card with the local provider, charges it on its own schedule, and then creates a genuine paid order back in the store.

That last step is the whole design. Because the store sees a real order rather than a note about one, everything downstream — stock, fulfilment, the email platform — fires normally and knows nothing about the bridge. No parallel universe of subscription orders to reconcile later.

Anything that reads product labels automatically depends on a model reading small print off a curved, glare-lit tub photographed in a shop aisle. Trusting that it works is not the same as checking.

So I photographed 25 real products in-store, then separately tracked down each manufacturer's own published nutrition panel — an independent source that knew nothing about my photos — and compared the two, value by value.

What it doesn't establish: 23 of the 25 products were curved tubs. Sachets and fine print are barely represented, so this says nothing about that failure mode. That limitation is written into the findings themselves, not left for a reader to notice.

A single screen that answers "what is happening in my business today". Eleven agents go and find out, all at the same time; a twelfth reads everything they came back with and writes the actual briefing in plain language.

A system that puts AI agents to work across my codebases, written directly against the model's API rather than on top of a framework, so the controls stay mine. It splits into two halves that never touch: a build side that plans, writes, criticises and tests a change — then stops, and hands a human a patch to approve — and a monitoring side that watches live payment and stock signals and reports what it finds.

The monitoring side can recommend a fix but is structurally forbidden from running one. Different jobs get different models by cost and by how much judgement they need: the strongest model plans and criticises, a mid-tier model writes and tests, the cheapest one does the frequent, shallow watching.

Every new app I build starts from the same foundation: sign-in, error reporting, background jobs, payment webhooks, forms, file uploads, money handling. The governing rule is that every piece works with no third-party accounts connected at all — a missing key means that capability is switched off with a clear message, never a crash. The automated checks enforce exactly that on every change.

The platform the reporting above sits on: public event pages, tiered ticket pricing, registration and payment, a QR code that gets scanned at the door, and the admin side behind it — attendees, sponsors and suppliers.

Payment confirmation arrives by webhook rather than by trusting the browser to come back, because the customer closing the tab after paying is normal behaviour and must not cost them their ticket. Access to data is enforced at the database itself, not only in the application, so a mistake in a page can't expose another event's attendee list.

An unused PC rebuilt as the machine everything else runs on: reachable from my laptop and phone anywhere in the world over a private network rather than anything exposed to the public internet, with terminal access, full remote desktop, a continuously synced notes vault, and push alerts to my phone when something needs attention.

A customer answers a short quiz and gets back a personalised image generated on the spot — something they'd actually save or share, rather than a discount code. Behind it: scoring, abandonment tracking, rate limiting, content moderation on anything a user types, short links, and the plumbing to pass what was learned into the email platform.

One repository holds the business itself — what we sell and why, pricing, operations, brand voice, marketing, the strategic decisions and the dates they were taken. Every other project points at it as the single source of truth, so a fact lives in exactly one place and the projects hold only what's specific to them.

It's structured for retrieval rather than for reading: each repository opens with a table saying which document to load for which question, so an AI session pulls two relevant files instead of thirty irrelevant ones. Decisions are dated and kept even when superseded — including the ones that were reversed, and why — so a later session can't unknowingly re-argue something already settled.

The list of members to be debited each month was assembled twice, in two systems, by two processes. Any divergence is money — either taken from someone who shouldn't have been charged, or not taken from someone who should.

No AI anywhere in the path that compares the money. A model is the wrong instrument for arithmetic that has to be right every time and has to be explainable to a member who disputes it. Same for the related tool that works out what each cancellation actually costs under the gym's own contract rules.

A creator wanted to stop guessing at what makes short-form video land. The system pulls a video apart — sampling frames, transcribing the audio on the machine rather than shipping it to a third party, reading on-screen captions locally — and tags it against a library of 21 named storytelling techniques. Every tag must cite a timestamp or a direct quote, so any claim can be checked. Built for many separate accounts from the first line, because it's meant to be sold on.

An approval queue, so nothing reaches a customer without a person saying yes — and once something is sent it can never be sent twice. A shadow mode that runs the system against real data while writing nothing, so its decisions can be compared against what the human actually did before anyone trusts it. Automatic stripping of personal identifiers. A cost ledger whose price list expires on purpose, so it can't quietly go stale and start reporting fiction.

None of these were built in response to something going wrong. That's the point.