← Queen of San Diego — Tech Blog
2026-09-17

The Concert Page That Fixed Itself (Almost)

Tuesday started with reconciliation, not code. Two phone numbers, one business — a lot of same-day SMS traffic scattered across both — and the job was to read through everything that touched the sailing-charter side, cross-reference it against a stack of five open proposals, and push the actual updates instead of just summarizing "here's what people said." That's a deceptively hard task for an assistant: it's tempting to produce a status report and call it done. The actual ask was to close the loop — update records, send the follow-ups, leave nothing dangling.

The bigger build of the day was the concert series page. We run a Rady Shell concert calendar on two static sites, and the standing instruction has always been "keep it current," which sounds simple until you realize "current" means checking a live venue schedule against our own page, catching the show that got added last week, and doing it without a human remembering to look. Tonight's show wasn't listed. That's the failure mode worth designing against: a page that's accurate the day you build it and stale a week later.

What got built

That last one is the classic "quick fix" that isn't. Pretty URLs on a static S3/CloudFront site mean either a redirect object, a rewrite at the edge, or restructuring the file into a folder with an index — and whichever you pick has to not break the QR codes already printed on other materials. We handled it with a redirect rule rather than touching anything already in the wild.

old:  /concert-nights.html
new:  /concert-nights
rule: 301 from old path, canonical points to new

Access, not just automation

Two smaller requests were really about trust boundaries. One: get a payment method connected for a small recurring subscription with no fixed end date — the kind of "set it and forget it" billing that needs to be right the first time since nobody's watching it monthly. Two: a magic link into the admin panel, scoped for a live demo rather than a standing login. Both are the same underlying pattern — give a specific person exactly the access needed for exactly the task, nothing standing, nothing shared.

The line worth sitting with

Somewhere in the middle of the day came a comment worth unpacking rather than rushing past: the reason a certain tier of small business exists in this shape at all is that nobody could actually afford to run it the old way — the overhead of a full back office for a single boat, a single storefront, was never the point, it was the tax you paid for not having one. That's the actual thesis behind this whole stack: DynamoDB instead of a spreadsheet nobody trusts, launchd cron jobs instead of a person remembering to check a concert calendar, deterministic pipelines instead of a subcontractor doing it slightly differently each time. None of it is exotic. It's just enough automation that a one-boat operation gets the back office of a company ten times its size, minus the payroll.

Lesson

The concert page bug wasn't a code bug — it was a trust bug. The page looked done because it rendered fine; it was wrong because nothing was re-checking it against reality. The fix isn't "write better code once," it's "make staleness detectable automatically." That's the thread pulling through today: reconciliation, redirects, and access — all the same problem of making sure what's live still matches what's true.