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

Registering a Second Domain Taught Me More About My Own Stack Than the Domain Did

Tuesday started with a yak-shave. I wanted to grab a second domain for a side project adjacent to the charter business, so I wrote a quick boto3 script against Route53Domains to register it headlessly instead of clicking through the console. It died on line 10, mid-call, on the contact block — AdminContact wasn't shaped the way the API wanted it. Nothing dramatic, just a reminder that AWS's domain-registration API is pickier about contact schemas than S3 or DynamoDB ever are. I fixed the contact dict and moved on, but it was a useful nudge: every time I bolt a new AWS service onto this stack, I should expect one undocumented shape mismatch before it works.

The fleet is getting bigger than the scripts

The more interesting theme of the day wasn't any single script — it was how much of my actual work now is managing other processes instead of writing code directly. I had a background delete job silently get killed partway through clearing out an old guest folder. I had a provisioning wait-job time out before the resource it was waiting on ever came up. Neither one was a bug in the traditional sense — they were jobs that just... stopped, with no stack trace to grep. The debugging instinct for "a script crashed" and the debugging instinct for "a background job went quiet" are completely different muscles, and I'm still building the second one.

Same day, I had a research subagent — call it the LLC-research hand — go off, do its work, and report back to a "team lead" process instead of straight to me. That's a new shape for this stack: agents reporting to agents, with me reading the summary instead of the transcript. It's efficient, but it means I have to trust the handoff more than I'd trust a script's exit code. I don't fully trust it yet.

The gates held, as usual

Meanwhile the boring, reliable parts of the stack kept doing their job without asking for credit. The Krystal publish-plan runner ran its daily gate before anything went out to Instagram — check the plan, check for a hard "go": false, and if it's not a clean go, stop and don't publish. No surprises there, which is exactly the point of a gate like that.

The nightly code reviewer also did its usual pass over the day's diff — not looking for style nits, just the handful of things that actually matter in a one-person production shop: could this send a guest the wrong message, charge the wrong card, or quietly break a deploy. It came back clean. A clean nightly review isn't exciting to write about, but it's the whole reason the rest of the day's experimentation — new domains, new subagent chains, background jobs that occasionally go dark — is safe to keep running. The deterministic, boring layer is what lets the flashy, agentic layer take risks.

Lesson

The failure mode worth watching for isn't "the script threw an exception" anymore — it's "the job went quiet and I didn't notice." Killed background tasks and silent timeouts don't leave a traceback; they leave a gap. As this stack grows more agents talking to other agents, the monitoring question matters more than the automation question. Writing the pipeline was the easy part. Noticing when a piece of it stops breathing is the part I'm still working on.