← Queen of San Diego — Tech Blog
2026-10-01

Running JADA's ops stack today, not sailing it

Some days are boat days. Today was an infrastructure day — the kind where you realize the thing slowing down the business isn't the dock schedule, it's you, trying to track six parallel AI sessions in your head like air traffic control with no radar.

Too many sessions, not enough situational awareness

The estate currently runs work across a laptop and a Lightsail box, with background sessions spinning up for everything from charter-prep checklists to domain maintenance. The problem isn't capacity, it's visibility. I asked for a pass through every running session on the Lightsail instance — rank them, kill the ones that aren't load-bearing right now. Half of them turned out to be stale investigations nobody was waiting on. The other half were real and just needed to keep running quietly in the background.

That exercise surfaced an uncomfortable constraint: a single session can quietly eat all the RAM on a small box if you let several run at once. The fix isn't clever — it's discipline. One active session per box at a time, background tasks capped, and a habit of checking what's actually alive before spinning up a new one. No orchestration magic here, just treating compute like dock space: finite, and worth a manifest.

Email ownership is infrastructure, not a vendor bill

A domain's MX records changed somewhere in the shuffle between sessions, which is exactly the kind of silent, high-blast-radius edit that should never happen without a human signing off. The resolution wasn't technical, it was a policy call: if you own the domain, you own the mail flowing through it, full stop — not a recurring per-seat fee to a mail provider for the privilege of using your own name. Lesson logged for every future session touching DNS: treat MX/DNS changes like a database migration, not a config tweak. Confirm before, don't discover after.

Building a cockpit for the work itself

The more interesting build today was turning progress.queenofsandiego.com into an actual mission-control board — something that shows every open ticket and background task at a glance, with drill-down into status changes, linked tickets, notes, and photo/video attachments uploaded straight from a phone. The old board could do most of that; the ask was to keep every bit of that functionality while giving the whole thing a sharper UI pass. Cards need to be clickable all the way down — status, history, media — because "sitrep on everything else" should be a page you open, not a question you have to ask an assistant and wait on.

That's the real lesson from today: the AI-assisted ops stack scales fine on the automation side — pipelines, SMS drafts, deploy scripts, publish-plan checks — but it does not scale on the human-attention side unless there's a single source of truth for what's running and why. Build the dashboard before you build the tenth background job, not after.

Still deterministic where it counts

None of this touched the parts of the stack that actually move money or guests — the charter-prep coordination with the marina for an upcoming trip, the vendor sourcing for an event, the publish-plan gate that still refuses to go live on a bad JSON payload. Those stayed exactly as boring and deterministic as they should be. Today was about making the boring parts visible, so the next infrastructure fire gets caught on a dashboard instead of in a frantic "check all the sessions" request.

Rule of the day: one session per box, DNS changes need a human sign-off,
and if you can't see your own background work, you don't actually have an ops stack —
you have a pile of cron jobs with good intentions.