A month ago I wrote about leaving a $250/year Evernote subscription for a self-hosted setup on a Mac mini, where the real point was an AI layer — "Ask My Notes" — that answers questions across fifteen years of notes. This week I pushed that system somewhere I didn't expect when I started: it now reads my daily journal and keeps a structured history of my own health. And, separately, I built a loop that lets me rebuild the iPhone app itself from my phone and install the new version by tapping a link.
Different-looking features, same underlying idea: use AI to do the tedious work that was previously not worth doing by hand, and keep the sensitive parts on hardware I own.
An AI that keeps my health history for me
Buried inside years of freeform daily journal entries is a surprising amount of health-relevant signal — medications and doses, how I slept, symptoms and side effects, workouts, the occasional weight or blood-pressure reading. It's all in there, but it's prose, scattered across thousands of days. Answering a simple longitudinal question like "how did my sleep change over the course of a particular year?" by hand means reading a year of entries and taking notes on your own notes. Nobody does that. So the information may as well not exist.
So I taught the system to do it. A worker on the mini walks the journal one day at a time. For each day it makes exactly one zero-retention LLM call that pulls out structured health events and drops the rest — categorized as medication, sleep, symptom, exercise, or measurement, each with a short item and a one-line detail. Those events land in a local table, and from them the worker regenerates browsable notes that sync into Joplin like anything else: a rolling recent-window "Health Timeline," plus one "Health Timeline — YYYY" archive note per year, so the full history is scrollable on any device.
It's incremental. Each day-section is hashed, so a day only re-extracts when I actually append something to it — a backfill of the whole archive happens once, and after that it's a trickle. And because those events are in the same index the assistant already queries, I can now just ask: "when did I start taking X," "how did my sleep trend across a given year," "what did my training look like last spring" — in plain language, and get an answer stitched together across years of entries, with citations back to the exact journal days it drew from. (I'm keeping my actual answers to myself — but that's the shape of the questions.)
The guardrail is the interesting engineering, not the extraction. Two things matter more than the feature itself:
- Health questions are sandboxed at the database level. When I ask a health question, the query runs under a SQLite authorizer that allowlists reads to the health-events table and nothing else. It's not a polite convention in a prompt — a health-scoped question literally cannot read the rest of my notes, enforced by the database engine. The categories of thing I'm most careful about get the tightest blast radius.
- The private content only ever leaves on zero-retention terms. Extraction uses the same strictest-first, zero-data-retention path the assistant already uses for this journal; the embeddings that make everything searchable run locally on the mini. A corpus with medication logs in it doesn't get handed to anything that keeps it.
That privacy posture is also why this app is, deliberately, not a product. I keep it dev-sideloaded onto my own devices — no App Store listing, no TestFlight — precisely because it's a single-user client talking to a private server that holds medical data. Shipping it publicly would mean an Apple review surface and an account system I have no reason to want. The right distribution for a personal medical tool is no distribution.
One honest war story from building it: an automated pipeline that runs unattended has to fail safely. Early on, an out-of-credits error from the model provider (a plain HTTP 402) was quietly burning queued days into a permanent "error" state every polling cycle — so a billing hiccup would have silently punched holes in the timeline. The fix was to treat provider-side failures (rate limits, 5xx, network drops, out-of-credits) as transient: the day stays pending and retries next cycle, and only genuinely unusable content is ever marked terminal. Building the extractor was an afternoon. Making it trustworthy enough to run against my own health history unattended was the actual work.
Rebuilding the app from my phone
The second thing this week was a tangent I stumbled into and then couldn't stop using.
Because the whole system runs on an always-on Mac mini, and because I can reach a coding session on that mini from my phone through Claude Code's remote control, I can now do something that still feels slightly illicit: from my phone, away from my desk, I describe a change I want in the iPhone app; the agent on the mini edits the code, builds a fresh signed build, and hands me back a link; I tap the link, and iOS installs the new version onto my Home Screen. I never touch a computer.
The part that makes this non-obvious is the install. The normal way to put a development build on an iPhone needs the phone on the same local network as the Mac — a USB cable or Bonjour on the home Wi-Fi. That's useless when I'm not home. So instead, the build drops its .ipa plus a tiny metadata sidecar into a folder, and a small service on the mini serves an itms-services install page — the same mechanism enterprises use for internal app distribution. The catch with itms-services is that iOS flatly refuses it over anything but real HTTPS with a trusted certificate. My private network already solves that: it hands out a genuine Let's Encrypt certificate for the mini, so the install page is served over a real HTTPS URL that iOS trusts, reachable from anywhere the phone has the tunnel up. A signed, single-use token guards the link, and the builds install only on my own registered devices.
It's also app-agnostic. Any of my repos can drop a build into that folder and it shows up on the install page automatically — so "send myself a new build to try" went from a desk-bound chore with a cable to a link I tap on the couch. The device-install path that needs the local network became one that doesn't.
The bigger point is the shape of the loop: think of a change on the phone, hand it to the machine that's always on and always has my tools, and get the running result back on the phone — wherever I am. The mini does the compiling and the heavy lifting; the phone is just the terminal I happen to be holding.
Why this matters
Neither of these is a thing you could buy. An app that reads your journal and maintains your health history, with a hard database-level guarantee that a health question can't wander into the rest of your notes, is not a feature any note-taking company is going to ship you — and if they did, your medical history would live on their servers. The rebuild-from-my-phone loop only exists because the whole stack is mine to wire together.
That's the throughline with the rest of what I build: own the infrastructure, keep the sensitive data on my own machines, and spend the AI on the work that was previously too tedious to do at all — like turning fifteen years of scattered journal entries into a health chart you can actually ask questions of. This is the kind of custom, precisely-fitted infrastructure I build with AI at Slick Engineering & Consulting, Inc. — most of it, like this, for an audience of one.