Systems I've built, and how each one works.

Content Multiplier

Content pipeline

The problem it solves is boring and expensive: a founder sits for one video a week, and turning that into a week of posts across five platforms takes a person two full days. Every week. Forever.

So the transcript goes in and the week comes out. Captions per platform per cut, LinkedIn posts, quote cards rendered as finished images, a newsletter with its banner, carousels, one-pagers, and a full YouTube package with titles, chapters and thumbnails. Everything lands on a posting calendar rather than in a folder someone has to open.

The interesting engineering is not the writing. It's the part that assumes the model will misbehave. A parser that expects the output to be malformed and fixes it. Length caps per platform. Automatic re-rolls when a piece comes back wrong. A publish hold that stops anything questionable before it reaches a real feed. The voice profile is cached as a single prefix, which is what makes running it every week cost pocket change instead of a salary.

Engagement Co-Pilot

Engagement system

Commenting under the right people is how a small account gets found. It also quietly eats an hour a day, which is why almost nobody keeps it up past week three.

This watches the creators you care about, reads what they actually posted (it will pull a video and listen to it rather than guess from a caption), and drafts comments in your voice. They stack up in a review queue. You skim, edit anything that's off, and send.

The design decision worth understanding: it never presses Post. The browser extension fills the box and a person sends it. It reads posts the way any signed-out visitor does, never through your login session, and it makes no attempt to look like something it isn't. Platforms restrict accounts for automated activity, and both of the enforcement waves I've watched went straight at logged-in automation and comment volume. So the automation stops at the draft. You keep the click, and there is nothing on the account to flag.

Replies to comments on your own posts run through official integrations, with caps, spacing and quiet hours. Anything that looks like a question, a complaint or a lead is held back for you instead of answered automatically. Private messages are never answered by the system at all.

Motion graphics, written as code

Video production system

Motion graphics are the usual bottleneck in a content operation. One designer, a queue, a week of turnaround, and a look that drifts every time somebody new touches it.

These shots are React components rendered to video, which changes what a house style even is. Type scale, palette, spacing, timing, the minimum frames a caption has to stay on screen: those stop being a habit somebody remembers and become rules in a file. A shot that breaks one fails its check instead of quietly shipping. Every animated shot carries its own sound bed, storyboards as a still first, and renders a small draft before anything goes to full resolution.

The harder half is moving it. What makes an AI workflow good is almost never in the project folder. It's the accumulated rules, the memory of every correction, the exact tool versions, the environment. Copy the files to a teammate and you move none of that, which is why handing over a folder never works. So I built the kit that captures the rest: it reads the setup's own state, interviews the person using it for what only lives in their head, writes all of it into plain files any machine can read, then installs on the new machine and refuses to pass until three sample frames match the reference.

Clinic records, read from paper

Records system

A paediatric clinic with three sites and around thirteen thousand paper charts. Nobody is going to stop seeing patients to type those in, and no amount of good software fixes a backlog that big by asking staff to retype it.

So the phone does the reading. Photograph a chart, and the fields come back marked by how sure the system is: green where it is confident, amber where a human needs to look, red where the form was blank. Nothing saves on its own. A person confirms every record, and the original photograph stays attached to it forever.

The test that convinced me it was worth building used a real handwritten prescription. It came back correct in one pass. The one ambiguous item, a quantity written as a range, was flagged for confirmation rather than guessed at. The weight field, blank on the paper, stayed blank on the screen. That last part matters more than accuracy: a records system that invents a plausible number is worse than no system.

Around it sits the ordinary but necessary work. Growth curves on the standard percentiles, a vaccine register with dose calculations, per-person logins with real role limits, an access log the clinic owns, encrypted nightly backups, and short-lived links on private storage.

CounterBook

Counter system for a coffee shop

There is plenty of free point-of-sale software, so building one needs a reason. Here are two.

The senior citizen discount. Philippine law says the discount comes off after the sales tax is removed, not before. Every off-the-shelf tool I tested applies the twenty percent to the tax-inclusive price instead, which overcharges a senior by about forty-three pesos on a five hundred peso bill. That is not a rounding error, it is a compliance problem the owner would carry. So the discount engine does it in the right order, and captures the identification the law requires.

The counter has to work when the internet doesn't. The register keeps its own local copy and its own outbox. Order identifiers are generated and stored on the device before any network call, so a retry reuses the order instead of creating a second one. Money is held as whole centavos, never as a decimal that drifts.

The receipt rule shapes the whole design: software that prints a customer's official invoice needs government accreditation, so this one never prints one. It prints order slips carrying the required wording, and the paperwork stays where it legally belongs.

Ops system for a water treatment business

Operations system

A supplier who installs and services water treatment equipment across two towns. The customer list lived in a notebook and a phone. The question that actually loses money is simple and nobody could answer it: which of the units we installed are due for a filter change this month?

So the system is built around installed equipment rather than around invoices. Every customer carries the units they own and the service intervals those units need, which turns maintenance from something remembered into something scheduled. Around that: quotations that print, orders with partial and unpaid balances tracked the way the business actually sells, an install pipeline, a service board, stock with low-stock flags, and a receivables view by age.

The website and the ops system are one build, not two. An enquiry from the site does not land in an inbox nobody checks. It arrives on the shop's own screen as a customer and a job, in two taps.

Clip pipeline

Short-form production

A long stream is mostly filler with a few genuinely good minutes inside it, and finding those by scrubbing a timeline is the least valuable way a person can spend an evening.

This one takes the recording, transcribes it, and reads the transcript for moments worth cutting, scoring each one rather than taking the first hit. It cross-checks against two signals a transcript can't see: where the audio suddenly gets louder, and where the live chat spiked. Then it renders the vertical cuts with word-level captions and a hook burned into the opening seconds, and drops them in a local gallery to review.

It runs on my own machine and my own graphics card, which is the whole point. Per-clip cost is close to nothing.