Practice

Built usage and cost governance from scratch: live rate-limit metering read directly from provider API headers, which the client library leaves unexposed, plus a pacing dial and quota-guarded scheduling.

Ran a full security audit of the fleet's own write access, self-directed. The documented claim was one gate to main; the practice was six ungated paths. Root cause was capability creep — each addition individually justified, while the count stayed where it was. Fixed with server-side git hooks enforcing a namespace allow-list, ownership and permissions set so the constrained process is unable to edit the control meant to constrain it, and history-rewrite protection. Kill-tested both directions before I trusted it.

I run five automated helpers on my own hardware, unattended. Each one works in its own sealed copy of the files and can only write to one place, so a mistake stays in its own corner.

I built the cost controls from scratch, reading the usage figures the provider sends back in each reply, which their own toolkit leaves out.

Then I audited my own setup off my own bat, and found six ways those helpers could write where the documentation claimed there was one. The cause was ordinary: each addition made sense on its own, while the count stayed where it was. I fixed it so the guard sits out of reach of the thing it guards, and I tried to break it both ways before trusting it.

Full stack with no external dependencies. State as version-controlled plaintext, a commit gate that closes on error — it aborts and alerts where an out-of-scope write would otherwise pass, a slug-authenticated public API on the standard library, reminder scheduling and stale-thread detection over push, and per-client localisation.

Hand-built calendar feed generation to RFC 5545, added after checking whether the target calendar app has a write API. The resulting one-way limit is stated in the product.

Constant-time token comparison, rate limiting, strict CORS, and a runtime identity gate that caught a real gap the build-time check was unable to see.

A booking system, built because I left a reply unanswered for three weeks and was carrying deadlines in my head.

Everything is stored as plain text under version control, so the history is readable and it all stays as files you can open. It refuses and warns where something out of place would otherwise be saved quietly, and it sends reminders by push.

I wrote the calendar feed by hand after checking whether the calendar app I use can accept one the other way. It accepts only one direction, and the app says so plainly on the page.

Defects diagnosed from plain-language feedback by finding the mechanism each time. A sound described as static traced to a hard amplitude step in an envelope function; described clipping traced to unbudgeted signal summation. Both fixed at the signal level.

Permissions as a product feature: no network permission, the claim readable from the manifest, and a build gate that halts a release that acquires one.

Distribution constraints handled as they appeared, including a hosting platform's terms changing mid-project — found by reading the actual clause. The plan moved; the product held.

BreathGate, an Android app I built end to end: the interface, the animation, and the sound, which is generated on the phone rather than played from a file.

When something felt wrong I looked for the actual cause. A sound described as 'static' turned out to be a sharp jump in volume; described 'clipping' turned out to be layers adding up past what the speaker could take. Both fixed at the source.

It asks for no internet access, you can check that before installing, and the release process stops if a build ever acquires it.

Speech recognition, a voice pipeline with activity detection, and synthesis, all running on my own hardware behind an authenticated route.

Measured the network before trusting a framework: two STUN queries from one socket returned different external ports, which is symmetric NAT, and under it peer-to-peer traversal stays out of reach here. The websocket transport is simply the correct answer here, and finding that out cost two build cycles I would rather have spent elsewhere.

Cut spoken-turn latency from about five seconds to under two by sizing the decoder window to the utterance, then verified the transcripts were byte-identical at three lengths so the speed-up cost no accuracy.

A way to talk to my own machine and hear it answer, with no outside company anywhere in the audio.

Speech recognition, the conversation itself, and the voice all run on hardware I own, reached over an authenticated connection.

I measured the network before trusting the software, and found the connection type that rules out direct peer-to-peer here. Better to find that out with a measurement than after two rebuilds. I also cut the delay on short questions from about five seconds to under two, then checked the results were word-for-word identical so the speed cost no accuracy.